The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.
In summary:
* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream
- SMBus Controller
- SATA Controller
- HD Audio Controller
- Watchdog Controller
Thanks to Seth Heasley (seth.heasley@intel.com) for providing us code.
MFC after 3 days
apply AR8152 v1.0 specific initialization code. Fix this bug by
explicitly reading PCI device revision id via PCI accessor.
Reported by: Gabriel Linder ( linder.gabriel <> gmail dot com )
After inspecting the ath9k source, it seems the AR5416 and later MACs
don't take an explicit RTS/CTS duration. A per-scenario (ie, what multi-
rate retry became) rts/cts control flag and packet duration is provided;
the hardware then apparently fills in whatever details are required.
The per-rate sp/lpack duration calculation just isn't used anywhere
in the ath9k TX packet length calculations.
The burst duration register controls something different; it seems to
be involved with RTS/CTS protection of 11n aggregate frames and is set
via a call to ar5416Set11nBurstDuration().
I've done some light testing with rts/cts protected frames and nothing
seems to break; but this may break said RTS/CTS and CTS-to-self protection.
that represents the host controller. This makes the FDT PCI support
working an a bare-bones manner. This needs a lot more work, of which
the beginning are at the end of the file, compiled-out with #if 0.
The intend being that both the Marvell PCIE and Freescale PCI/PCIX/PCIE
duplicate the same platform-independent domain initialization, that
should be moved into an unified implementation in the FDT code. Handling
of resources requires help from the platform. A unified implementation
allows us to properly support PCI devices listed in the device tree and
configured according to the device tree specification.
Sponsored by: Juniper Networks
Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.
Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.
Write a default value if there's no history available.
This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)
* I messed up a couple of things in if_athvar.h; so fix that.
* Undo some guesswork done in ar5416Set11nRateScenario() and introduce a
flags parameter which lets the caller set a few things. To begin with,
this includes whether to do RTS or CTS protection.
* If both RTS and CTS is set, only do RTS. Both RTS and CTS shouldn't be
set on a frame.
There's two reasons for this:
* the raw and non-raw TX path shares a lot of duplicate code which should be
refactored;
* the 11n-ready chip TX path needs a little reworking.
receive processing.
Remove unnecessary restrictions on the mbuf chain length built during an
LRO receive. This restriction was copied from the Linux netfront driver
where the LRO implementation cannot handle more than 18 discontinuities.
The FreeBSD implementation has no such restriction.
MFC after: 1 week
This is just the bare minimum needed to teach ath_rate_sample to try
and handle MCS rates. It doesn't at all attempt to find the best
rate by any means - it doesn't know anything about the MCS rate
relations, TX aggregation or any of the much sexier 11n stuff
that's out there.
It's just enough to transmit 11n frames and handle TX completion.
It shouldn't affect legacy (11abg) behaviour.
Obtained from: rpaulo@
This will eventually be used by rate control modules and by the TX
code for calculating packet duration when handling rts/cts protection.
Obtained from: sam@, rpaulo@, linux ath9k
covering the whole page, free the page. Otherwise, clear the region and
mark it clean. Not marking the page dirty could reinstantiate cleared
data, but it is allowed by BIO_DELETE specification and saves unneeded
write to swap.
Reviewed by: alc
Tested by: pho
MFC after: 2 weeks
The defaults enabled three chains on the AR5416 even if the card has two
chains. This restores that and ensures that only the correct TX/RX
chainmasks are used.
When HT modes are enabled, all TX chains will be correctly enabled.
This should now enable analog chain swapping with 2-chain cards.
I'm not sure if this is needed for just the AR5416 or whether
it also applies to AR9160, AR9280 and AR9287 (later on); I'll have
to get clarification.
This, along with an initval change which will appear in a subsequent commit,
fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro
(AR7161 MIPS board.)
Obtained from: Linux ath9k
PR: kern/154220
sbuf_new_for_sysctl(9). This allows using an sbuf with a SYSCTL_OUT
drain for extremely large amounts of data where the caller knows that
appropriate references are held, and sleeping is not an issue.
Inspired by: rwatson
the controller has a kind of embedded controller/memory and vendor
applies a large set of magic code via undocumented PHY registers in
device initialization stage. I guess it's a firmware image for the
embedded controller in RTL8105E since the code is too big compared
to other DSP fixups. However I have no idea what that magic code
does and what's purpose of the embedded controller. Fortunately
driver seems to still work without loading the firmware.
While I'm here change device description of RTL810xE controller.
H/W donated by: Realtek Semiconductor Corp.
exact model name is not clear yet. All previous RTL8201 10/100 PHYs
used 0x8201 in MII_PHYIDR2 which in turn makes model number 0x20
but this PHY used new model number 0x08.
capability. One of reason using interrupt taskqueue in re(4) was
to reduce number of TX/RX interrupts under load because re(4)
controllers have no good TX/RX interrupt moderation mechanism.
Basic TX interrupt moderation is done by hardware for most
controllers but RX interrupt moderation through undocumented
register showed poor RX performance so it was disabled in r215025.
Using taskqueue to handle RX interrupt greatly reduced number of
interrupts but re(4) consumed all available CPU cycles to run the
taskqueue under high TX/RX network load. This can happen even with
RTL810x fast ethernet controller and I believe this is not
acceptable for most systems.
To mitigate the issue, use one-shot timer register to moderate RX
interrupts. The timer register provides programmable one-shot timer
and can be used to suppress interrupt generation. The timer runs at
125MHZ on PCIe controllers so the minimum time allowed for the
timer is 8ns. Data sheet says the register is 32 bits but
experimentation shows only lower 13 bits are valid so maximum time
that can be programmed is 65.528us. This yields theoretical maximum
number of RX interrupts that could be generated per second is about
15260. Combined with TX completion interrupts re(4) shall generate
less than 20k interrupts. This number is still slightly high
compared to other intelligent ethernet controllers but system is
very responsive even under high network load.
Introduce sysctl variable dev.re.%d.int_rx_mod that controls amount
of time to delay RX interrupt processing in units of us. Value 0
completely disables RX interrupt moderation. To provide old
behavior for controllers that have MSI/MSI-X capability, introduce
a new tunable hw.re.intr_filter. If the tunable is set to non-zero
value, driver will use interrupt taskqueue. The default value of
the tunable is 0. This tunable has no effect on controllers that
has no MSI/MSI-X capability or if MSI/MSI-X is explicitly disabled
by administrator.
While I'm here cleanup interrupt setup/teardown since re(4) uses
single MSI/MSI-X message at this moment.
ath9k does a few different things here during config - if it's an early
AR5416 with two chains, it enables all three chains for calibration and
then restores the chainmask to the original values after initial
calibration has completed.
The reason behind this commit is to begin breaking out the chainmask
configuration for this specific reason; follow-up commits will add
the chainmask restore in the ar5416Reset() routine.
recent PCIe controllers(RTL8102E or later and RTL8168/8111C or
later) supports either 2 or 4 MSI-X messages. Unfortunately vendor
did not publicly release RSS related information yet. However
switching to MSI-X is one-step forward to support RSS.
RTL8111C generated corrupted frames where TCP option header was
broken. All other sample controllers I have did not show such
problem so it could be RTL8111C specific issue. Because there are
too many variants it's hard to tell how many controllers have such
issue. Just disable TSO by default but have user override it.
* Re-do the structure size/component math to make sure the struct matches
the expected size
* Just to be clear that we care about bitmask ordering, revert my previous
change and instead define that macro if we're on big-endian.
It turns out that the V4K eeprom definitions (used by the AR9285 and
its derivatives) is wrong. These values are at least causing issues
on my AR2427.
With this fix (and initvals in a subsequent commit), the AR2427 behaves
a lot better.
Note - there's still significant drift between the ath9k v4k eeprom
init code (again, used by AR9285 and derivatives) and what's in this
tree. That needs to be investigated and resolved.
prevent sending data when CTS is de-asserted.
In uart_tty_intr(), call uart_tty_outwakeup() when the CTS signal
changed, knowing that uart_tty_outwakeup() will do the right
thing for flow control. This avoids redundant conditionals.
PR: kern/148644
Submitted by: John Wehle <john@feith.com>
MFC after: 3 days
via AHCI-like memory resource at BAR(5). Use it if BIOS was so kind to
allocate memory for that BAR. This allows hot-plug support and connection
speed reporting.
MFC after: 2 weeks
controllers. Experimentation with RTL8102E, RTL8103E and RTL8105E
showed dramatic decrement of TX completion interrupts under high TX
load(e.g. from 147k interrupts/second to 10k interrupts/second)
With this change, TX interrupt moderation is applied to all
controllers except RTL8139C+.
The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.
Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k
interfaces just returned the base header. There's extra information
outside of that which would also be nice to get access to.
The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.
Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.
value. While I'm here enable all clocks before initializing
controller. This change should fix lockup issue seen on AR8152
v1.1 PCIe Fast Ethernet controller.
PR: kern/154076
MFC after: 3 days
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
This removes the chipset-dependent TX DMA completion descriptor groveling.
It should now be (more) portable to other, later atheros chipsets when the
time comes.
The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.
I believe earlier parts can do something similar but I haven't
experienced it first-hand.
This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
Since we now have the source code, there's no reason to hide the diag codes
from other areas.
They live in the HAL as they form part of the HAL API and should still be treate
as "potentially flexible; don't publish as a public API." But since they're
already used as a public API (see follow-up commit), we may as well use
them in place of magic constants.
CRITICAL FIX - with stats changes the older 82598 will panic
and trash the stack on driver load, FCOE registers ONLY exist
in 82599 and must not be read otherwise.
kern/153951 - to correct incorrect media type on adapters
with pluggable modules I have eliminated the old static
table in favor of a new dynamic shared code routine. This
also has the benefit of detecting changes when a different
module is inserted.
Performance/enhancement to the Flow Director code from my
linux coworker (the developer of the code).
Fixes from Michael Tuexen - a data corruption problem on the
82599 (CRITICAL), fix so the buf size correctly adjusts as
the cluster changes, and max descriptors are set properly.
Also added 16K clusters for those REALLY big jumbos :)
In the RX path, the RX LOCK was not being released, and this
causes LOR problems. Add the code that igb already has.
Sync with in house shared code, this was necessary for the
Flow Director fix.
MFC in 2 days
reading. (This was already done for writing to a sysctl). This
requires all SYSCTL setups to specify a type. Most of them are now
checked at compile-time.
Remove SYSCTL_*X* sysctl additions as the print being in hex should be
controlled by the -x flag to sysctl(8).
Succested by: bde
for this sensor. Instead of leaving this location empty we use here
the default name 'sensor'.
Submitted by: Justin Hibbits <chmeeedalf at gmail dot com>
Approved by: nwhitehorn (mentor)
DP8381[56] and SiS 900/7016 controllers. After r212119, sis(4) no
longer reinitializes controller if ALLMULTI/PROMISC was changed.
However, RX filter handling code assumed some bits of the RX filter
is programmed by driver initialization. This caused ALLMULTI/PROMISC
configuration is ignored under certain conditions.
Fix that issue by reprogramming all bits of RX filter register.
While I'm here follow recommended RX filter programming steps
recommended by National DP8381[56] data sheet(RX filter should be
is disabled before programming).
Reported by: Paul Schenkeveld < freebsd () psconsult dot nl >
Tested by: Paul Schenkeveld < freebsd () psconsult dot nl >
MFC after: 3 days
- Remove extra unlock from end of ale_start_locked().
- Expand scope of locking in interrupt handler.
- Move ether_ifdetach() earlier and retire now-unneeded DETACH flag.
Tested by: Aryeh Friedman
Reviewed by: yongari (earlier version)
doesn't "fail", it may merely return garbage if it is not a valid ivar
for a given device. Our parent device must be a 'pcib' device, so we
can just assume it implements pcib IVARs, and all pcib devices have a
bus number.
Submitted by: clang via rdivacky
Compile sys/dev/mem/memutil.c for all supported platforms and remove now
unnecessary dev_mem_md_init(). Consistently define mem_range_softc from
mem.c for all platforms. Add missing #include guards for machine/memdev.h
and sys/memrange.h. Clean up some nearby style(9) nits.
MFC after: 1 month
This fixes hostap mode for at least ral(4) and run(4), because there is
no sufficient call into drivers which could be used initialize the node
related ratectl variables.
MFC after: 3 days
GbE controllers. It seems these controllers no longer support
multi-fragmented RX buffers such that driver have to allocate
physically contiguous buffers.
o Retire RL_FLAG_NOJUMBO flag and introduce RL_FLAG_JUMBOV2 to
mark controllers that use new jumbo frame scheme.
o Configure PCIe max read request size to 4096 for standard frames
and reduce it to 512 for jumbo frames.
o TSO/checksum offloading is not supported for jumbo frames on
these controllers. Reflect it to ioctl handler and driver
initialization.
o Remove unused rl_stats_no_timeout in softc.
o Embed a pointer to structure rl_hwrev into softc to keep track
of controller MTU limitation and remove rl_hwrev in softc since
that information is available through a pointer to structure
rl_hwrev.
Special thanks to Realtek for donating sample hardwares which made
this possible.
H/W donated by: Realtek Semiconductor Corp.
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Just let the default case handle all unsupported media types.
- In pnphy_status() don't unnecessarily read a register twice.
- Remove unnused macros.
MFC after: 1 week
configuration, which is used to work around issues with certain setups
(see r161237) by default, should not be triggered as it may in turn
cause harm in some edge cases.
- Even after masking the media with IFM_GMASK the result may have bits
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Announce PAUSE support also for manually selected 1000BASE-T, but for
all manually selected media types only in full-duplex mode. Announce
asymmetric PAUSE support only for manually selected 1000BASE-T.
- Simplify setting the manual configuration bits to only once after we
have figured them all out. This also means we no longer unnecessarily
update the hardware along the road.
- Remove a stale comment.
Reviewed by: yongari (plus additional testing)
MFC after: 3 days
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Simplify ciphy_service() to only set the manual configuration bits
once after we have figured them all out. This also means we no longer
unnecessarily update the hardware along the road.
MFC after: 1 week
complicates the code.
- Don't let atphy_setmedia() announce PAUSE support for half-duplex when
MIIF_FORCEPAUSE is set.
- Simplify e1000phy_service() and ip1000phy_service() to only set the
manual configuration bits once after we have figured them all out. For
ip1000phy_service() this also means we no longer unnecessarily update
the hardware along the road.
MFC after: 1 week
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
md(4) to using M_WAITOK malloc calls.
M_NOWAITOK allocations may fail when enough memory could be freed, but not
immediately. E.g. SU UFS becomes quite unhappy when metadata write return
error, that would happen for failed malloc() call.
Reported and tested by: pho
MFC after: 1 week
table is present, then the acpi_ec(4) driver will allocate its resources
from nexus0 before the acpi0 device reserves resources for child devices.
Reviewed by: jkim
manual 1000BASE-T modes of DP83865 only work together with other National
Semiconductor PHYs.
- Spell 10BASE-T correctly
- Remove some redundant braces.
condition in proc_rwmem() and to (2) simplify the implementation of the
cxgb driver's vm_fault_hold_user_pages(). Specifically, in proc_rwmem()
the requested read or write could fail because the targeted page could be
reclaimed between the calls to vm_fault() and vm_page_hold().
In collaboration with: kib@
MFC after: 6 weeks
the original amd64 and i386 headers with stubs.
Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere.
Reviewed by: imp (previous version), jhb
Approved by: kib (mentor)
controller with Card Read Host Controller. These controllers are
multi-function devices and have the same ethernet core of
JMC250/JMC260. Starting from REVFM 5(chip full mask revision)
controllers have the following features.
o eFuse support
o PCD(Packet Completion Deferring)
o More advanced PHY power saving
Because these controllers started to use eFuse, station address
modified by driver is permanent as if it was written to EEPROM. If
you have to change station address please save your controller
default address to safe place before reprogramming it. There is no
way to restore factory default station address.
Many thanks to JMicron for continuing to support FreeBSD.
HW donated by: JMicron
a 2GHz channel with appropriate flags set to sc->config. Due to not zeroing
sc->config for auth/assoc those flags are still set while trying to connect
on a 5GHz channel.
MFC after: 3 days
Use pci_enable_busmaster instead of setting PCIM_CMD_BUSMASTEREN
directly. There's no need to set PCIM_CMD_MEMEN. The bit is set when a
SYS_RES_MEMORY resource is activated.
Remove redundant pci_* function calls from suspend/resume methods. The
bus driver already saves and restores the PCI configuration.
Write 1 byte instead of 4 when setting the HIFN_TRDY_TIMEOUT register.
It is only 1 byte according to the specification.
Reviewed by: jhb
Approved by: kib (mentor)
configuration registers directly.
Remove pci_enable_io calls where they are redundant. The PCI bus driver
will set the right bits when the corresponding bus resource is activated.
Remove redundant pci_* function calls from suspend/resume methods. The
bus driver already saves and restores the PCI configuration.
Reviewed by: jhb
Approved by: kib (mentor)
This is based on the patch submitted by Yuri Skripachov.
Overview of the changes:
- clarify double-use of some ACPI_BATT_STAT_* definitions
- clean up undefined/extended status bits returned by _BST
- warn about charging+discharging bits being set at the same time
PR: kern/124744
Submitted by: Yuri Skripachov <y.skripachov@gmail.com>
Tested by: Yuri Skripachov <y.skripachov@gmail.com>
MFC after: 2 weeks
allow the child atkbd device to reuse that IRQ resource instead of
reallocating the same IRQ from the parent bus inside the atkbd driver.
- Don't allocate a shared IRQ for the atkbd driver. For AT keyboard
devices on an ISA bus the IRQ is not shareable. Instead, the bus driver
should mark the IRQ shareable if the bus supports shared IRQs.
- Don't identify child devices until after the atkbdc device itself has
attached.
delete the IRQ resource from the psmcpnp device completely.
- Don't allocate the IRQ resource shared. It is not a shareable interrupt
on ISA. The bus driver can set RF_SHAREABLE if the IRQ is actually
shareable on a non-ISA bus.
- Avoid side-effect assignments in if statements when possible.
- Don't use ! to check for NULL pointers, explicitly check against NULL.
- Explicitly check error return values against 0.
- Don't use INTR_MPSAFE for interrupt handlers with only filters as it is
meaningless.
- Remove unneeded function casts.
function always returned the nominal frequency instead of current frequency
because we use RDTSC instruction to calculate difference in CPU ticks, which
is supposedly constant for the case. Now we support cpu_get_nominal_mhz()
for the case, instead. Note it should be just enough for most usage cases
because cpu_est_clockrate() is often times abused to find maximum frequency
of the processor.
There is no need to use an atomic operation at structure initialization
time.
Note that the file changed is not connected to the build at this time.
Reviewed by: jhb (general issue)
Approved by: np
MFC after: 2 weeks
Prior to this change, the addressing method wasn't getting set, and
so the LUN field could be set incorrectly in some instances.
This fix should allow for LUN numbers up to 16777215 (and return an error
for anything larger, which wouldn't fit into the flat addressing model).
Submitted by: scottl (in part)
This bug manifested itself after repeated device arrivals and
departures. The root of the problem was that the last entry in the
reply array wasn't initialized/allocated. So every time we got
around to that event, we had a bogus address.
There were a couple more problems with the code that are also fixed:
- The reply mechanism was being treated as sequential (indexed by
sc->replycurindex) even though the spec says that the driver
should use the ReplyFrameAddress field of the post queue
descriptor to figure out where the reply is. There is no
guarantee that the reply descriptors will be used in sequential
order.
- The second word of the reply post queue descriptor wasn't being
checked in mps_intr_locked() to make sure that it wasn't
0xffffffff. So the driver could potentially come across a
partially DMAed descriptor.
- The number of replies allocated was one less than the actual
size of the queue. Instead, it was the size of the number of
replies that can be used at one time. (Which is one less than
the size of the queue.)
mps.c: When initializing the entries in the reply free
queue, make sure we initialize the full number that
we tell the chip we have (sc->fqdepth), not the
number that can be used at any one time (sc->num_replies).
When allocating replies, make sure we allocate the
number of replies that we've told the chip exist,
not just the number that can be used simultaneously.
Use the ReplyFrameAddress field of the post queue
descriptor to figure out which reply is being
referenced. This is what the spec says to do, and
the spec doesn't guarantee that the replies will be
used in order.
Put a check in to verify that the reply address passed
back from the card is valid. (Panic if it isn't, we'll
panic when we try to deference the reply pointer in any
case.)
In mps_intr_locked(), verify that the second word of the
post queue descriptor is not 0xffffffff in addition to
verifying that the unused flag is not set, so we can
make sure we didn't get a partially DMAed descriptor.
Remove references to sc->replycurindex, it isn't needed
now.
mpsvar.h: Remove replycurindex from the softc, it isn't needed now.
Reviewed by: scottl
functionality is the same, a difference is that the DS1775 has a better
precision than the LM75. But we do not use it in our setup. Make the
LM75 work the same as the DS1775.
Fix a typo in device_set_desc.
Tested by: Paul Mather <paul at gromit dlib vt edu>
Approved by: nwhitehorn (mentor)
pointer where data is to be returned by ibask() (currently unimplemented),
while __retval holds the value returned by the libgpib ibfoo() functions.
The confusion resulted in the ibfoo() functions returning an uninitialized
value except in situations where the GPIB activity has been terminated
abnormally.
MFC after: 3 days
re-arming the watchdog timeout.
Sponsored by: Sandvine Incorporated
Submitted by: Mark Johnston <mjohnston at sandvine dot com>
Reviewed by: des
MFC after: 10 days
AX88772 controllers. ASIX added a new feature for AX88178/AX88772
controllers which allows combining multiple TX frames into a single
big frame. This was to overcome one of USB limitation where it
can't generate more than 8k interrupts/sec which in turn means USB
ethernet controllers can not send more than 8k packets per second.
Using ASIX's feature greatly enhanced TX performance(more than 3~4
times) compared to 7.x driver. However it seems r184610 removed
boundary checking for buffered frames which in turn caused
instability issues under certain conditions. In addition, using
ASIX's feature triggered another issue which made USB controller
hang under certain conditions. Restarting ethernet controller
didn't help under this hang condition and unplugging and replugging
the controller was the only solution. I believe there is a silicon
bug in TX frame combining feature on AX88178/AX88772 controllers.
To address these issues, reintroduce the boundary checking for both
AX88178 and AX88772 after copying a frame to USB buffer and do not
use ASIX's multiple frame combining feature. Instead, use USB
controller's multi-frame transmit capability to enhance TX
performance as suggested by Hans[1].
This should fix a long standing axe(4) instability issues reported
on AX88772 and AX88178 controllers. While I'm here remove
unnecessary TX frame length check since upper stack always
guarantee the size of a frame to be less than MCLBYTES.
Special thanks to Derrick Brashear who tried numerous patches
during last 4 months and waited real fix with patience. Without
this enthusiastic support, patience and H/W donation I couldn't fix
it since I was not able to trigger the issue on my box.
Suggested by: hselasky [1]
Tested by: Derrick Brashear (shadow <> gmail dot com>
H/W donated by: Derrick Brashear (shadow <> gmail dot com>
PR: usb/140883
isn't configurable in a meaningful way. This is for ifconfig(8) or
other tools not to change code whenever IFT_USB-like interfaces are
registered at the interface list.
Reviewed by: brooks
No objections: gavin, jkim
looking to see if there is an existing IRQ resource for a given IRQ
provided by the BIOS and using that RID if so. Otherwise, allocate a new
RID for the new IRQ.
Reviewed by: mav (a while ago)
max_request_segments * PAGE_SIZE if the I/O is page-aligned; the
largest I/O we can guarantee will work is PAGE_SIZE less than that.
This unbreaks 'diskinfo -t'.
as an association ID is set any scan is supposed to be a background scan.
This implies that the firmware will switch back to the associated channel
after a certain threshold, though, we are not notified about that. We
currently catch this case by a timer which will reset the firmware after
a 'scan timeout', though, upper layers are not notified about that and
will simply hang until manual intervention. Fix this by resetting the
firmware's knowledge about any association on RUN -> ASSOC and
!INIT -> SCAN transitions.
Tested by: Zhihao Yuan <lichray at gmail.com>
MFC after: 1 week
- Do not call iwn_calib_reset() for monitor mode. We do not want to query
information and do runtime calibration while in monitor mode. Poking the
firmware with adjustments for calibration results in firmware asserts.
This could happened on RUN -> RUN transition only.
- Adjust blink rate for monitor mode. It's supposed to not freak out and
turn off after a while.
- While here, remove one useless assignment of calib.state, it gets
overwritten later in the function.
Submitted by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 1 week
preserve the upper bits of the first data byte.
While here, shorten a few nearby lines.
PR: kern/152768
Reported by: Sascha Wildner saw of online.de
Reviewed by: scottl
MFC after: 1 week
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.
MFC after: 1 week
the size can be smaller than the constant when you are
doing HW TAGGING, and you still need to process this
packet in a normal way. I'm not sure where the notion
to just return came from, but its wrong.
MFC after: 3 days
Second, correct the discard/refresh_mbufs code to behave
more like igb, there have been panics due to discards and
this should fix them.
MFC after: 3 days
finding. The test to compare the mbuf m_len against
a fixed value and then returning needs to be removed.
When using VLANS and doing HW_TAGGING, and IPV6, the
ICMP6 packets actually fail this condition, the constant
assumes that the tag is IN the frame, and its not, so
the length is actually tiny. Furthermore, I'm not sure
what the point was to just return??
MFC after: 3 days
the controller to workaround silicon bug of i82557. Each reset will
re-establish link which in turn triggers MII status change
callback. The callback will try to reconfigure controller if the
controller is not i82557 to enable flow-control. This caused
endless link UP/DOWN when the workaround was enabled on non-i82557
controller.
To fix the issue, apply RX lockup workaround only for i82557.
Previously it blindly checked undocumented EEPROM location such
that it sometimes enabled the workaround for other controllers. At
this time, only i82557 is known to have the silicon bug.
This fixes a regression introduced in r215906 which enabled flow
control support for all controllers except i82557.
Reported by: Karl Denninger (karl <> denninger dot net)
Tested by: Karl Denninger (karl <> denninger dot net)
MFC after: 3 days
or detached. Normally it should be changed through user land ioctl(2)
system calls but it looks there's no apps for USB and no need.
With this patch, libpcap would detect the usbus interfaces correctly and
tcpdump(1) could dump the USB packets into PCAP format with -w option.
However it couldn't print the output to console because there's no
printer-routine at tcpdump(1).
This includes support in the kernel, camcontrol(8), libcam and the mps(4)
driver for SMP passthrough.
The CAM SCSI probe code has been modified to fetch Inquiry VPD page 0x00
to determine supported pages, and will now fetch page 0x83 in addition to
page 0x80 if supported.
Add two new CAM CCBs, XPT_SMP_IO, and XPT_GDEV_ADVINFO. The SMP CCB is
intended for SMP requests and responses. The ADVINFO is currently used to
fetch cached VPD page 0x83 data from the transport layer, but is intended
to be extensible to fetch other types of device-specific data.
SMP-only devices are not currently represented in the CAM topology, and so
the current semantics are that the SIM will route SMP CCBs to either the
addressed device, if it contains an SMP target, or its parent, if it
contains an SMP target. (This is noted in cam_ccb.h, since it will change
later once we have the ability to have SMP-only devices in CAM's topology.)
smp_all.c,
smp_all.h: New helper routines for SMP. This includes
SMP request building routines, response parsing
routines, error decoding routines, and structure
definitions for a number of SMP commands.
libcam/Makefile: Add smp_all.c to libcam, so that SMP functionality
is available to userland applications.
camcontrol.8,
camcontrol.c: Add smp passthrough support to camcontrol. Several
new subcommands are now available:
'smpcmd' functions much like 'cmd', except that it
allows the user to send generic SMP commands.
'smprg' sends the SMP report general command, and
displays the decoded output. It will automatically
fetch extended output if it is available.
'smppc' sends the SMP phy control command, with any
number of potential options. Among other things,
this allows the user to reset a phy on a SAS
expander, or disable a phy on an expander.
'smpmaninfo' sends the SMP report manufacturer
information and displays the decoded output.
'smpphylist' displays a list of phys on an
expander, and the CAM devices attached to those
phys, if any.
cam.h,
cam.c: Add a status value for SMP errors
(CAM_SMP_STATUS_ERROR).
Add a missing description for CAM_SCSI_IT_NEXUS_LOST.
Add support for SMP commands to cam_error_string().
cam_ccb.h: Rename the CAM_DIR_RESV flag to CAM_DIR_BOTH. SMP
commands are by nature bi-directional, and we may
need to support bi-directional SCSI commands later.
Add the XPT_SMP_IO CCB. Since SMP commands are
bi-directional, there are pointers for both the
request and response.
Add a fill routine for SMP CCBs.
Add the XPT_GDEV_ADVINFO CCB. This is currently
used to fetch cached page 0x83 data from the
transport later, but is extensible to fetch many
other types of data.
cam_periph.c: Add support in cam_periph_mapmem() for XPT_SMP_IO
and XPT_GDEV_ADVINFO CCBs.
cam_xpt.c: Add support for executing XPT_SMP_IO CCBs.
cam_xpt_internal.h: Add fields for VPD pages 0x00 and 0x83 in struct
cam_ed.
scsi_all.c: Add scsi_get_sas_addr(), a function that parses
VPD page 0x83 data and pulls out a SAS address.
scsi_all.h: Add VPD page 0x00 and 0x83 structures, and a
prototype for scsi_get_sas_addr().
scsi_pass.c: Add support for mapping buffers in XPT_SMP_IO and
XPT_GDEV_ADVINFO CCBs.
scsi_xpt.c: In the SCSI probe code, first ask the device for
VPD page 0x00. If any VPD pages are supported,
that page is required to be implemented. Based on
the response, we may probe for the serial number
(page 0x80) or device id (page 0x83).
Add support for the XPT_GDEV_ADVINFO CCB.
sys/conf/files: Add smp_all.c.
mps.c: Add support for passing in a uio in mps_map_command(),
so we can map a S/G list at once.
Add support for SMP passthrough commands in
mps_data_cb(). SMP is a special case, because the
first buffer in the S/G list is outbound and the
second buffer is inbound.
Add support for warning the user if the busdma code
comes back with more buffers than will work for the
command. This will, for example, help the user
determine why an SMP command failed if busdma comes
back with three buffers.
mps_pci.c: Add sys/uio.h.
mps_sas.c: Add the SAS address and the parent handle to the
list of fields we pull from device page 0 and cache
in struct mpssas_target. These are needed for SMP
passthrough.
Add support for the XPT_SMP_IO CCB. For now, this
CCB is routed to the addressed device if it supports
SMP, or to its parent if it does not and the parent
does. This is necessary because CAM does not
currently support SMP-only nodes in the topology.
Make SMP passthrough support conditional on
__FreeBSD_version >= 900026. This will make it
easier to MFC this change to the driver without
MFCing the CAM changes as well.
mps_user.c: Un-staticize mpi_init_sge() so we can use it for
the SMP passthrough code.
mpsvar.h: Add a uio and iovecs into struct mps_command for
SMP passthrough commands.
Add a cm_max_segs field to struct mps_command so
that we can warn the user if busdma comes back with
too many segments.
Clear the cm_reply when a command gets freed. If
it is not cleared, reply frames will eventually get
freed into the pool multiple times and corrupt the
pool. (This fix is from scottl.)
Add a prototype for mpi_init_sge().
sys/param.h: Bump __FreeBSD_version to 900026 for the for the
inclusion of the XPT_GDEV_ADVINFO and XPT_SMP_IO
CAM CCBs.
versions of FreeBSD. In fact we are already missing a lot of conditional
code necessary to support older versions of FreeBSD, including alternatives
for vital functionality not yet provided by the respective subsystem back
then (see for example r199663). So this change shouldn't actually break
this driver on versions of FreeBSD that were supported before. Besides,
this driver also isn't maintained as an multi-release version outside of
the main repository, so removing the conditional code shouldn't be a
problem in that regard either.
- Sprinkle some more const on tables.
hence existing applications like webcamd are expecting that.
This problem was introduced by SVN change 214221 where cdev=
was replaced by ugen= by accident. Solve this problem by
redefining cdev= in devd notifications.
MFC after 3 days.
Approved by: thompsa (mentor)
i.e. alignment, max_address, max_iosize and segsize (only max_address is
thought to have an negative impact regarding this issue though), after
calling ata_dmainit() either directly or indirectly so these values have
no effect or at least no effect on the DMA tags and the defaults are used
for the latter instead. So change the drivers to set these parameters
up-front and ata_dmainit() to honor them.
Reviewd by: mav
MFC after: 1 month
