CAM.
Desriptor sense is a new sense data format that originated in SPC-3. Among
other things, it allows for an 8-byte info field, which is necessary to
pass back block numbers larger than 4 bytes.
This change adds a number of new functions to scsi_all.c (and therefore
libcam) that abstract out most access to sense data.
This includes a bump of CAM_VERSION, because the CCB ABI has changed.
Userland programs that use the CAM pass(4) driver will need to be
recompiled.
camcontrol.c: Change uses of scsi_extract_sense() to use
scsi_extract_sense_len().
Use scsi_get_sks() instead of accessing sense key specific
data directly.
scsi_modes: Update the control mode page to the latest version (SPC-4).
scsi_cmds.c,
scsi_target.c: Change references to struct scsi_sense_data to struct
scsi_sense_data_fixed. This should be changed to allow the
user to specify fixed or descriptor sense, and then use
scsi_set_sense_data() to build the sense data.
ps3cdrom.c: Use scsi_set_sense_data() instead of setting sense data
manually.
cam_periph.c: Use scsi_extract_sense_len() instead of using
scsi_extract_sense() or accessing sense data directly.
cam_ccb.h: Bump the CAM_VERSION from 0x15 to 0x16. The change of
struct scsi_sense_data from 32 to 252 bytes changes the
size of struct ccb_scsiio, but not the size of union ccb.
So the version must be bumped to prevent structure
mis-matches.
scsi_all.h: Lots of updated SCSI sense data and other structures.
Add function prototypes for the new sense data functions.
Take out the inline implementation of scsi_extract_sense().
It is now too large to put in a header file.
Add macros to calculate whether fields are present and
filled in fixed and descriptor sense data
scsi_all.c: In scsi_op_desc(), allow the user to pass in NULL inquiry
data, and we'll assume a direct access device in that case.
Changed the SCSI RESERVED sense key name and description
to COMPLETED, as it is now defined in the spec.
Change the error recovery action for a number of read errors
to prevent lots of retries when the drive has said that the
block isn't accessible. This speeds up reconstruction of
the block by any RAID software running on top of the drive
(e.g. ZFS).
In scsi_sense_desc(), allow for invalid sense key numbers.
This allows calling this routine without checking the input
values first.
Change scsi_error_action() to use scsi_extract_sense_len(),
and handle things when invalid asc/ascq values are
encountered.
Add a new routine, scsi_desc_iterate(), that will call the
supplied function for every descriptor in descriptor format
sense data.
Add scsi_set_sense_data(), and scsi_set_sense_data_va(),
which build descriptor and fixed format sense data. They
currently default to fixed format sense data.
Add a number of scsi_get_*() functions, which get different
types of sense data fields from either fixed or descriptor
format sense data, if the data is present.
Add a number of scsi_*_sbuf() functions, which print
formatted versions of various sense data fields. These
functions work for either fixed or descriptor sense.
Add a number of scsi_sense_*_sbuf() functions, which have a
standard calling interface and print the indicated field.
These functions take descriptors only.
Add scsi_sense_desc_sbuf(), which will print a formatted
version of the given sense descriptor.
Pull out a majority of the scsi_sense_sbuf() function and
put it into scsi_sense_only_sbuf(). This allows callers
that don't use struct ccb_scsiio to easily utilize the
printing routines. Revamp that function to handle
descriptor sense and use the new sense fetching and
printing routines.
Move scsi_extract_sense() into scsi_all.c, and implement it
in terms of the new function, scsi_extract_sense_len().
The _len() version takes a length (which should be the
sense length - residual) and can indicate which fields are
present and valid in the sense data.
Add a couple of new scsi_get_*() routines to get the sense
key, asc, and ascq only.
mly.c: Rename struct scsi_sense_data to struct
scsi_sense_data_fixed.
sbp_targ.c: Use the new sense fetching routines to get sense data
instead of accessing it directly.
sbp.c: Change the firewire/SCSI sense data transformation code to
use struct scsi_sense_data_fixed instead of struct
scsi_sense_data. This should be changed later to use
scsi_set_sense_data().
ciss.c: Calculate the sense residual properly. Use
scsi_get_sense_key() to fetch the sense key.
mps_sas.c,
mpt_cam.c: Set the sense residual properly.
iir.c: Use scsi_set_sense_data() instead of building sense data by
hand.
iscsi_subr.c: Use scsi_extract_sense_len() instead of grabbing sense data
directly.
umass.c: Use scsi_set_sense_data() to build sense data.
Grab the sense key using scsi_get_sense_key().
Calculate the sense residual properly.
isp_freebsd.h: Use scsi_get_*() routines to grab asc, ascq, and sense key
values.
Calculate and set the sense residual.
MFC after: 3 days
Sponsored by: Spectra Logic Corporation
- Implement bus_adjust_resource() methods as far as necessary and in non-PCI
bridge drivers as far as feasible without rototilling them.
- As NEW_PCIB does a layering violation by activating resources at layers
above pci(4) without previously bubbling up their allocation there, move
the assignment of bus tags and handles from the bus_alloc_resource() to
the bus_activate_resource() methods like at least the other NEW_PCIB
enabled architectures do. This is somewhat unfortunate as previously
sparc64 (ab)used resource activation to indicate whether SYS_RES_MEMORY
resources should be mapped into KVA, which is only necessary if their
going to be accessed via the pointer returned from rman_get_virtual() but
not for bus_space(9) as the later always uses physical access on sparc64.
Besides wasting KVA if we always map in SYS_RES_MEMORY resources, a driver
also may deliberately not map them in if the firmware already has done so,
possibly in a special way. So in order to still allow a driver to decide
whether a SYS_RES_MEMORY resource should be mapped into KVA we let it
indicate that by calling bus_space_map(9) with BUS_SPACE_MAP_LINEAR as
actually documented in the bus_space(9) page. This is implemented by
allocating a separate bus tag per SYS_RES_MEMORY resource and passing the
resource via the previously unused bus tag cookie so we later on can call
rman_set_virtual() in sparc64_bus_mem_map(). As a side effect this now
also allows to actually indicate that a SYS_RES_MEMORY resource should be
mapped in as cacheable and/or read-only via BUS_SPACE_MAP_CACHEABLE and
BUS_SPACE_MAP_READONLY respectively.
- Do some minor cleanup like taking advantage of rman_init_from_resource(),
factor out the common part of bus tag allocation into a newly added
sparc64_alloc_bus_tag(), hook up some missing newbus methods and replace
some homegrown versions with the generic counterparts etc.
- While at it, let apb_attach() (which can't use the generic NEW_PCIB code
as APB bridges just don't have the base and limit registers implemented)
regarding the config space registers cached in pcib_softc and the SYSCTL
reporting nodes set up.
* The AR_ISR_RAC interrupt processing method has a subtle bug in all
the MAC revisions (including pre-11n NICs) until AR9300v2.
If you're unlucky, the clear phase clears an update to one of the
secondary registers, which includes TX status.
This shows up as a "watchdog timeout" if you're doing very low levels
of TX traffic. If you're doing a lot of non-11n TX traffic, you'll
end up receiving a TX interrupt from some later traffic anyway.
But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet
doing), you may find that you're only able to TX one frame (due to
BAW restrictions) and this may end up hitting this race condition.
The only solution is to not use RAC and instead use AR_ISR and the
AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary
registers are not cleared; only the AR_ISR_Sx bits are. This way
any updates which occur between the read and subsequent write will
stay asserted and (correctly) trigger a subsequent interrupt.
I've tested this on the AR5416, AR9160, AR9280. I will soon test
the AR9285 and AR9287.
* The AR_ISR TX and RX bits (and all others!) are set regardless of
whether the contents of the AR_IMR register. So if RX mitigation is
enabled, RXOK is going to be set in AR_ISR and it would normally set
HAL_INT_RX.
Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation
is compiled in. That way the RX path isn't prematurely called.
I would see:
* An interrupt would come in (eg a beacon, or TX completion) where
RXOK was set but RXINTM/RXMINT wasn't;
* ath_rx_proc() be called - completing RX frames;
* RXINTM/RXMINT would then fire;
* ath_rx_proc() would then be called again but find no frames in the
queue.
This fixes the RX mitigation behaviour to not overly call ath_rx_proc().
* Start to flesh out more correct timer interrupt handling - it isn't
kite/merlin specific. It's actually based on whether autosleep support
is enabled or not.
This is sourced from my 11n TX branch and has been tested for a few weeks.
Finally, the interrupt handling change should likely be implemented
for AR5210, AR5211 and AR5212.
There are some timing concerns which I've yet to fully map out.
In any case, there's an existing software driven mitigation method
for TX interrupts and when TX'ing 11n frames, the whole frame itself
generates an interrupt rather then the subframes.
Although I tried to fix this earlier by introducing HALDEBUG_G(), it
turns out there seem to be other cases where the pointer value is still
NULL.
* Fix DO_HALDEBUG() and the HALDEBUG macro to check whether ah is NULL
before deferencing it
* Remove HALDEBUG_G() as it's no longer needed
This is hopefully a merge candidate for 9.0-RELEASE as enabling
debugging at startup could result in a kernel panic.
by present MegaCLI version. It has some special meaning for the first s/g
list entry, while the main s/g list begins from the the second entry, and
those lists should remain separate after loading to the busdma map.
- Fix bug in 32bit ioctl compatibility shims when s/g list consists of
more then on element.
Sponsored by: iXsystems, inc.
MFC after: 3 days
Import the rest of HID improvements from the branch:
- improve report descriptor parser in libusbhid to handle several kinds of
reports same time;
- add to the libusbhid API two functions wrapping respective kernel IOCTLs
for reading and writing reports;
- tune uhid IOCTL interface to allow reading and writing arbitrary report,
when multiple supported by the device;
- teach usbhidctl to set output and feature reports;
- make usbhidaction support all the same item names as bhidctl.
Sponsored by: iXsystems, inc.
rather than the whole beacon interval.
The reference driver and Linux ath9k both choose 80% of the
beacon interval and they do it in the driver rather than
the HAL (Ath reference) or ath9k_hw (ath9k.)
This quietens stuck beacon conditions on my AR9220/AR9280
based NICs when a lot of burst broadcast/multicast traffic
is going on. It doesn't seem to annoy the earlier MACs as
much as the AR9280 and later one.
Obtained from: Linux ath9k, Atheros
local variable with a beacon interval of 100 TU. This never gets modified
if the beacon interval configuration changes.
This may have been correct in earlier times, but with the advent of
staggered beacons (which default to 1 / ATH_BCBUF beacon interval, so
25 TU here) this value is incorrect.
It is used to configure the default CABQ readytime. So here, the cabq
was being configured to be much greater than the target beacon timer
(TBTT.)
The driver should be configuring a cabq readytime value rather then
leaving it to the HAL to choose sensible defaults. This should be
done in the future - I'm simply trying to ensure sensible defaults
are chosen.
back-end features.
sys/dev/xen/netfront/netfront.c:
o Add xn_query_features() which reads the XenStore and
records the TSO, LRO, and chained ring-request support
of the backend.
o Rename xn_configure_lro() to xn_configure_features() and
use this routine to manage the setup of TSO, LRO, and
checksum offload.
o In create_netdev(), initialize if_capabilities and
if_hwassist to the capabilities found on all backends.
Delegate configuration of if_capenable and the TSO flag
if if_hwassist to xn_configure_features().
Reported by: Hugo Silva (fix inspired by patch provided)
Approved by: re
MFC after: 1 week
PV devices with the ioemu attribute set.
sys/dev/xen/netfront/netfront.c:
o If a mac address for the interface cannot be found
in the front-side XenStore tree, look for an entry
in the back-side tree. With ioemu devices, the
emulator does not populate the front side tree and
neither does Xend.
o Return an error rather than panic when an attach
attempt fails.
Reported by: Janne Snabb (fix inspired by patch provided)
PR: kern/154302
Approved by: re
Sponsored by: BQ Internet
sys/dev/xen/netfront/netfront.c:
o Implement netfront_suspend(), a specialized suspend
handler for the netfront driver. This routine simply
disables the carrier so the driver is idle during
system suspend processing.
o Fix a leak when re-initializing LRO during a link reset.
o In netif_release_tx_bufs(), when cleaning up the grant
references for our TX ring, use gnttab_end_foreign_access_ref
instead of attempting to grant the page again.
o In netif_release_tx_bufs(), we do not track mbufs associated
with mbuf chains, but instead just free each mbuf directly.
Use m_free(), not m_freem(), to avoid double frees of mbufs.
o Refactor some code to enhance clarity.
Approved by: re
MFC after: 1 week
Sponsored by: BQ Internet
sys/dev/xen/blkfront/block.h:
sys/dev/xen/blkfront/blkfront.c:
Remove now unused blkif_vdev_t from the blkfront soft.
sys/dev/xen/blkfront/blkfront.c:
o In blkfront_suspend(), indicate the desire to suspend
by changing the softc connected state to SUSPENDED, and
then wait for any I/O pending on the remote peer to
drain. Cancel suspend processing if I/O does not
drain within 30 seconds.
o Enable and update blkfront_resume(). Since I/O is
drained prior to the suspension of the VM, the complicated
recovery process performed by other Xen blkfront
implementations is avoided. We simply tear down the
connection to our old peer, and then re-connect.
o In blkif_initialize(), fix a resource leak and botched
return if we cannot allocate shadow memory for our
requests.
o In blkfront_backend_changed(), correct our response to
the XenbusStateInitialised state. This state indicates
that our backend peer has published sufficient data for
blkfront to publish ring information and other XenStore
data, not that a connection can occur. Blkfront now
will only perform connection processing in response to
the XenbusStateConnected state. This corrects an issue
where blkfront connected before the backend was ready
during resume processing.
Approved by: re
MFC after: 1 week
framework.
Sponsored by: BQ Internet
sys/xen/xenbus/xenbusb.c:
o In xenbusb_resume(), publish the state transition of the
resuming device into XenbusStateIntiailising so that the
remote peer can see it. Recording the state locally is
not sufficient to trigger a re-connect sequence.
o In xenbusb_resume(), defer new-bus resume processing until
after the remote peer's XenStore address has been updated.
The drivers may need to refer to this information during
resume processing.
sys/xen/xenbus/xenbusb_back.c:
sys/xen/xenbus/xenbusb_front.c:
Register xenbusb_resume() rather than bus_generic_resume()
as the handler for device_resume events.
sys/xen/xenstore/xenstore.c:
o Fix grammer in a comment.
o In xs_suspend(), pass suspend events on to the child
devices (e.g. xenbusb_front/back, that are attached
to the XenStore.
Approved by: re
MFC after: 1 week
This change fixes a race in device side mode during clear-stall from
host, which can cause data to be sent too early on the given
endpoint.
Approved by: re (kib)
MFC after: 1 week
initialization. Prior to this change packets may be transmitted with an
incorrect checksum.
Em(4) already has an equivalent change in r213234.
Obtained From: Sandvine
MFC After: 1 week
Approved by: re (bz)
patch modifies makesyscalls.sh to prefix all of the non-compatibility
calls (e.g. not linux_, freebsd32_) with sys_ and updates the kernel
entry points and all places in the code that use them. It also
fixes an additional name space collision between the kernel function
psignal and the libc function of the same name by renaming the kernel
psignal kern_psignal(). By introducing this change now we will ease future
MFCs that change syscalls.
Reviewed by: rwatson
Approved by: re (bz)
We are allocating some kilobytes of extra memory during USB device enumeration.
This does not change alot under FreeBSD, but makes sense for various embedded
operating systems using the FreeBSD USB stack, which have less memory
resources available.
Approved by: re (kib)
MFC after: 1 week
the BAR after parsing the CIS. This forces the resource range to be
reallocated if the BAR is reused by the device.
Submitted by: deischen
Reviewed by: imp
Approved by: re (kib)
This is another commit in a series of TDMA support fixes for the 11n NICs.
* Move ath_hal_getnexttbtt() into the HAL; write methods for it.
This returns a timer value in TSF, rather than TU.
* Move ath_hal_getcca() and ath_hal_setcca() into the HAL too, where they
likely now belong.
* Create a new HAL capability: HAL_CAP_LONG_RXDESC_TSF.
The pre-11n NICs write 15 bit TSF snapshots into the RX descriptor;
the AR5416 and later write 32 bit TSF snapshots into the RX descriptor.
* Use the new capability to choose between 15 and 31 bit TSF adjustment
functions in ath_extend_tsf().
* Write ar5416GetTsf64() and ar5416SetTsf64() methods.
ar5416GetTsf64() tries to compensate for TSF changes at the 32 bit boundary.
According to yin, this fixes the TDMA beaconing on 11n chipsets and TDMA
stations can now associate/talk, but there are still issues with traffic
stability which need to be investigated.
The ath_hal_extendtsf() function is also used in RX packet timestamping;
this may improve adhoc mode on the 11n chipsets. It also will affect the
timestamps seen in radiotap frames.
Submitted by: Kang Yin Su <cantona@cantona.net>
Approved by: re (kib)
whenever the link state is changed. Using software based polling
for media status tracking is known to cause MII access failure
under certain conditions once link is established so vge(4) used to
rely on link status change interrupt.
However DEVICE_POLLING completely disables generation of all kind
of interrupts on vge(4) such that this resulted in not detecting
link state change event. This means vge(4) does not correctly
detect established/lost link with DEVICE_POLLING. Losing the
interrupt made vge(4) not to send any packets to peer since vge(4)
does not try to send any packets when there is no established link.
Work around the issue by generating link state change interrupt
with DEVICE_POLLING.
PR: kern/160442
Approved by: re (kib)
reference driver does clear the async interrupts after each service.
I'll tinker with this in a future commit.
Obtained from: Atheros
Approved by: re (kib)
When the fast clock (44mhz) is enabled for 5ghz HT20, the
dual ADCs aren't enabled. Trying to do the ADC calibrations
here would result in calibration never completing; this
resulted in IQ calibration never running and thus performance
issues in 11a/11n HT20 mode.
Leave it enabled for non-fastclock (40mhz) 11a mode and
HT40 modes.
This has been fixed in discussion with Felix Fietkau (nbd)
and discussions with the Atheros baseband team.
Linux ath9k now has a similar fix.
Approved by: re (kib)
The current code was rounding down the maximum frame size instead of
routing up, resulting in a read size of 1024 bytes, in the non-jumbo
frame case, and splitting the packets across multiple mbufs.
Consequently the above problem exposed another issue, which is when
packets were splitted across multiple mbufs, and all of the mbufs in the
chain have the M_PKTHDR flag set.
Submitted by: original patch by Ray Ruvinskiy at BlueCoat dot com
Reviewed by: jfv, kmacy, rwatson
Approved by: re (rwatson)
MFC after: 5 days
is retrieved after a failed SCSI command to continue normal
operation. Else this sense information is retrived at the next
SCSI command.
Approved by: re (kib)
Reported by: Alex Kozlov
MFC after: 1 week
PR: usb/160299
which does not support the no synchronize cache SCSI command.
The __FreeBSD_version version macro has been bumped and
external kernel modules needs to be recompiled after
this patch.
Approved by: re (kib)
MFC after: 1 week
PR: usb/160299
- tjmax - Tj(max) value from the CPU
- delta - current delta reading
- resolution - sensor resolution in Celsius
- throttle_log - whether a #PROCHOT was asserted since last reset
Submitted by: Mark Johnston <markjdb gmail.com> (mostly)
MFC after: 1 month
Approved by: re (kib)
keyboards allow console break sequences (such as ctrl-alt-esc) to be
entered, alternative break can prove useful under virtualisation and
remote console systems where entering control sequences can be
difficult or unreliable.
MFC after: 3 weeks
Approved by: re (bz)
improvements:
(1) Implement new model in previously missed at91 UART driver
(2) Move BREAK_TO_DEBUGGER and ALT_BREAK_TO_DEBUGGER from opt_comconsole.h
to opt_kdb.h (spotted by np)
(3) Garbage collect now-unused opt_comconsole.h
MFC after: 3 weeks
Approved by: re (bz)
accessible:
(1) Always compile in support for breaking into the debugger if options
KDB is present in the kernel.
(2) Disable both by default, but allow them to be enabled via tunables
and sysctls debug.kdb.break_to_debugger and
debug.kdb.alt_break_to_debugger.
(3) options BREAK_TO_DEBUGGER and options ALT_BREAK_TO_DEBUGGER continue
to behave as before -- only now instead of compiling in
break-to-debugger support, they change the default values of the
above sysctls to enable those features by default. Current kernel
configurations should, therefore, continue to behave as expected.
(4) Migrate alternative break-to-debugger state machine logic out of
individual device drivers into centralised KDB code. This has a
number of upsides, but also one downside: it's now tricky to release
sio spin locks when entering the debugger, so we don't. However,
similar logic does not exist in other device drivers, including uart.
(5) dcons requires some special handling; unlike other console types, it
allows overriding KDB's own debugger selection, so we need a new
interface to KDB to allow that to work.
GENERIC kernels in -CURRENT will now support break-to-debugger as long as
appropriate boot/run-time options are set, which should improve the
debuggability of BETA kernels significantly.
MFC after: 3 weeks
Reviewed by: kib, nwhitehorn
Approved by: re (bz)
The AR5212 HAL didn't check this field; timers are enabled a different
way.
The AR5416 HAL however did, and since this field was uninitialised, it had
whatever was on the stack at the time. This lead to "unpredictable"
behaviour.
This allows TDMA to work on the AR5416 and later chipsets.
Thanks to: paradyse@gmail.com
Approved by: re (kib, blanket)
* Fix SLEEP1/SLEEP2 register definitions; the CAB/Beacon timeout
fields have changed in AR5416 and later
* The TIM_PERIOD and DTIM_PERIOD registers are now microsecond fields,
not TU.
Obtained from: Linux ath9k, Atheros reference
Approved by: re (kib, blanket)
or later. Previous hardware had some as TU, some as 1/8th
TU.
* Modify AR_NEXT_DBA and AR_NEXT_SWBA to use a new macro,
ONE_EIGHTH_TU_TO_USEC(), which converts the 1/8th TU
fields to USEC. This is just cosmetic and matches the
Atheros reference driver.
* Fix AR_NEXT_TBTT, which is USEC, not TU.
Submitted by: paradyse@gmail.com
Approved by: re (kib, blanket)
programming secret. The PHY would go into sleep state when it
detects no established link and it will re-establish link when the
cable is plugged in. Previously it failed to re-establish link
when the cable is plugged in such that it required to manually down
and up the interface again to make it work. This came from
incorrectly programmed hibernation parameters. According to
Atheros, each PHY chip requires different configuration for
hibernation and different vendor has different settings for the
same chip.
Disabling hibernation may consume more power but establishing link
looks more important than saving power.
Special thanks to Atheros for giving me instructions that disable
hibernation.
MFC after: 1 week
Approved by: re (kib)
isolated but also powered down after a reset and while they just work fine
[sic] when both is the case they don't if they are only deisolate but still
powered down. So in order to put PHYs in an overall normal operation mode
for the common case, ensure in mii_phy_reset() that they are not powered
down after a reset. Unfortunately, this only helps in case of BCM5421,
while BCM5709S apparently only work when they remain isolated and powered
down after a reset. So don't call mii_phy_reset() in brgphy_reset() and
implement the reset locally leaving the problematic bits alone. Effectively
this bypasses r221812 for brgphy(4).
Thanks to Justin Hibbits for doing a binary search in order to identify
the problematic commit.
PR: 157405, 158156
Reviewed by: yongari (mii_phy_reset() part)
Approved by: re (kib)
MFC after: 3 days
cores with temp in the range 101-105 have been found in the past.
Sponsored by: Sandvine Incorporated
Reviewed by: delphij, emaste
Approved by: re (kib)
MFC after: 3 days
avoid lost timer interrupts. Previous optimization attempt doing it only
for intervals less then 5000 ticks (~300us) reported to be unreliable by
some people. Probably because of some heavy SMI code on their boards.
Introduce additional safety interval of 128 counter ticks (~9us) between
programmed comparator and counter values to cover different cases of
delayed write found on some chipsets.
Approved by: re (kib)
to implement fchown(2) and fchmod(2) support for several file types
that previously lacked it. Add MAC entries for chown/chmod done on
posix shared memory and (old) in-kernel posix semaphores.
Based on the submission by: glebius
Reviewed by: rwatson
Approved by: re (bz)
mutex, which would lead to a deadlock.
Many thanks to Areca for their continued support of FreeBSD.
Submitted by: Ching Huang <ching2048 areca com tw>
Tested by: Willem Jan Withagen <wjw digiware nl>
MFC after: 3 days
Approved by: re (kib)
We also revive loop down freezes. We also externaliz within isp
isp_prt_endcmd so something outside the core module can print
something about a command completing. Also some work in progress to
assist in handling timed out commands better.
Partially Sponsored by: Panasas
Approved by: re (kib)
MFC after: 1 month
once. Use taskqueues to do the actual work.
Fix an offset line.
Fix isp_prt so that prints from just one buffer, which makes it
appear cleanly cleanly in logs on SMP systems.
Approved by: re (kib)
MFC after: 1 month
kernel for FreeBSD 9.0:
Add a new capability mask argument to fget(9) and friends, allowing system
call code to declare what capabilities are required when an integer file
descriptor is converted into an in-kernel struct file *. With options
CAPABILITIES compiled into the kernel, this enforces capability
protection; without, this change is effectively a no-op.
Some cases require special handling, such as mmap(2), which must preserve
information about the maximum rights at the time of mapping in the memory
map so that they can later be enforced in mprotect(2) -- this is done by
narrowing the rights in the existing max_protection field used for similar
purposes with file permissions.
In namei(9), we assert that the code is not reached from within capability
mode, as we're not yet ready to enforce namespace capabilities there.
This will follow in a later commit.
Update two capability names: CAP_EVENT and CAP_KEVENT become
CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they
represent.
Approved by: re (bz)
Submitted by: jonathan
Sponsored by: Google Inc
device having the same name like a previous one is not created before the old
one is gone. This fixes some panics due to asserts in the devfs code which
were added recently.
Approved by: re (kib)
MFC after: 1 week
- Ignore some more internal SAS device status change events.
- Correct inverted Bus and TargetID arguments in a warning.
o Add a warning for MPI_EVENT_SAS_DISCOVERY_ERROR events, which can help
identifying broken disks.
Submitted by: Andrew Boyer
Approved by: re (kib)
Committed from: Chaos Communication Camp 2011
ID. This fixes USB_SET_IMMED call (synchronous operation) of the uhid(4)
driver on devices with single report ID.
Reviewed by: hselasky
Approved by: re (kib)
MFC after: 1 week
needing this particular modification.
It can be called during ath_dfs_radar_enable() and still achieve the
same functionality, so I am.
Approved by: re (kib, blanket)
Remove this debugging, it's not needed anymore and when not enabled,
those variables trigger a compiler warning.
Approved by: re (kib, blanket)
Pointy-hat-to: adrian, for not testing a non-debug compile of this code enough
allows it to be overridden at runtime.
Thus, add a function which updates ah_dfsDomain after a channel set
call to ath_hal_set_channels().
Approved by: re (kib, blanket)
and the Atheros reference code.
The radar detection code needs to know what the current DFS domain is.
Since net80211 doesn't currently know this information, it's extracted
from the HAL regulatory domain information.
The specifics:
* add a new ath_dfs API hook, ath_dfs_init_radar_filters(), which
updates the radar filters whenever the regulatory domain changes.
* add HAL_DFS_DOMAIN which describes the currently configured DFS domain .
* add a new HAL internal variable which tracks the currently configured
HAL DFS domain.
* add a new HAL capability, HAL_CAP_DFS_DMN, which returns the currently
configured HAL DFS domain setting.
* update the HAL DFS domain setting whenever the channel setting is
updated.
Since this isn't currently used by any radar code, these should all
be no-ops for existing users.
Obtained from: Atheros
Submitted by: KBC Networks, sibridge
Approved by: re (kib, blanket)
if 5ghz fast clock is enabled in the current operating mode.
It's slightly dirty, but it's part of the reference HAL and used by
the (currently closed-source) radar event code to map radar pulses
back to microsecond durations.
Obtained from: Atheros
Approved by: re (kib, blanket)
the ar9130 code.
Since at least one kernel config specifies individual ath HAL chips
rather than just "device ath_hal" (arm/AVILA), I'm doing this so people
aren't caught out when they update to -HEAD or 9.0 and discover their
ath setup doesn't compile.
I'll revisit this with a proper fix sometime before 9.0-RELEASE.
Approved by: re (kib, blanket)
Pointed out by: ray@
Pointy hat to: adrian@
systems, in the same way that AR9130 embedded systems work.
This isn't -everything- that is required - the PCI glue still
needs to be taught about the eepromdata hint, along the same
lines as the AHB glue.
Approved by: re (kib, blanket)
Mac with this chipset does not initialize AHCI mode unless it is started
from EFI loader. However, legacy ATA mode works.
Submitted by: jkim@ (original version)
Approved by: re (kib)
MFC after: 1 week
truly.
Before 802.11n, the RX descriptor list would employ the "self-linked tail
descriptor" trick which linked the last descriptor back to itself.
This way, the RX engine would never hit the "end" of the list and stop
processing RX (and assert RXEOL) as it never hit a descriptor whose next
pointer was 0. It would just keep overwriting the last descriptor until
the software freed up some more RX descriptors and chained them onto the
end.
For 802.11n, this needs to stop as a self-linked RX descriptor tickles the
block-ack logic into ACK'ing whatever frames are received into that
self-linked descriptor - so in very busy periods, you could end up with
A-MPDU traffic that is ACKed but never received by the 802.11 stack.
This would cause some confusion as the ADDBA windows would suddenly
be out of sync.
So when that occured here, the last descriptor would be hit and the PCU
logic would stop. It would only start again when the RX descriptor list
was updated and the PCU RX engine was re-tickled. That wasn't being done,
so RXEOL would be continuously asserted and no RX would continue.
This patch introduces a new flag - sc->sc_kickpcu - which when set,
signals the RX task to kick the PCU after its processed whatever packets
it can. This way completed packets aren't discarded.
In case some other task gets called which resets the hardware, don't
update sc->sc_imask - instead, just update the hardware interrupt mask
directly and let either ath_rx_proc() or ath_reset() restore the imask
to its former setting.
Note: this bug was only triggered when doing a whole lot of frame snooping
with serial console IO in the RX task. This would defer interrupt processing
enough to cause an RX descriptor overflow. It doesn't happen in normal
conditions.
Approved by: re (kib, blanket)
interrupt storm.
This is easily triggered by flipping on and off tcpdump -y IEEE802_11_RADIO
w/ witness enabled. This causes a whole lot of console IO and when you're
attached to a serial console (eg on my AR7161 embedded board), the RX
interrupt doesn't get called quickly enough and the RX queue fills up.
This wasn't a problem in the past because of the self-linked RX descriptor
trick - the RX would never hit the "end" of the RX descriptor list.
However this isn't possible for 802.11n (see previous commit history for
why.)
Both Linux ath9k and the Atheros reference driver code do this; I'm just
looking now for where they then restart the PCU receive. Right now the RX
will just stop until the interface is reset.
Obtained from: Linux, Atheros
Approved by: re (kib)
The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.
This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.
I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)
Obtained from: Linux, Atheros
Approved by: re (kib)
This seems to indicate whether to program the NIC for fractional 5ghz
mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not.
The default (0) seems to mean "only program fractional mode if needed".
A different value (eg 1) seems to always enable fractional 5ghz mode
regardless of the frequency.
Obtained from: Atheros
Approved by: re (kib)
Calibration/PCI data that's written to flash (rather than EEPROM attached
to the NIC) is typically already in host-endian. The existing checks
end up swapping 16 bit words incorrectly - the correct solution would be
to read the magic value and determine the EEPROM endianness from that.
(This is what Linux does.)
This doesn't completely enable embedded use of the AR9285/AR9287 -
notably, the EEPROM read methods need to be made generic and available
to all EEPROM drivers. I'll worry about that later.
Approved by: re (kib)
* I messed up the order of parameter true/false; oops!
* AR_PHY_RADAR_1 was being written at the wrong place, and was writing
potential garbage to the hardware.
Approved by: re (kib)
* Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather
than calling the RX filter routines directly.
* Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available,
regardless of whether ah_ani_function is masking it.
* (Mostly) fully disable ANI if interference mitigation is disabled.
When disabled, the ANI code doesn't touch any ANI/PHY registers,
leaving them the default value. This is in line with what the
Atheros reference driver does.
* Correctly set the ANI parameters during ANI reset, rather than
when ANI is enabled. In this way, if ANI is disabled or enabled
whilst the NIC is not active (and there's no current channel),
bogus parameters or a NULL pointer deference doesn't occur.
There's still some lingering issues - notably, the MIB events/interrupts
aren't fully disabled, so MIB interrupts still occur. I'll worry about
that later.
Approved by: re (kib)
This in particular fixes radar PHY handling - on the AR5212
NIC, one enables the AR_PHY_ERR_RADAR bit in AR_PHY_ERR;
the AR5416 and later also needs a bit set in AR_RX_FILTER.
A follow-up commit is needed to convert the AR5416 ANI code
to use this particular method, as it's currently using the
AR5212 methods directly.
Obtained from: Atheros
Approved by: re (kib)
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.
Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.
Approved by: re (kib)
It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.
Obtained from: Atheros
Approved by: re (kib)
Although this may not be what the original sysctl was designed to do,
it feels a bit more "expected".
Before, if ANI is disabled, the initial ANI parameters are still written
to the hardware, even if they're not enabled. "ANI enabled" would then
adjust the noise immunity parameters dynamically. Disabling ANI would
simply leave the existing noise immunity parameters where they are,
and disable the dynamic part.
The problem is that disabling ANI doesn't leave the hardware in
a consistent, predictable state - so asking a user to disable ANI
wouldn't actually reset the NIC to a consistent set of PHY signal
detection parameters, resulting in an unpredictable/unreliable outcome.
This makes it difficult to get reliable debugging information from
the user.
Approved by: re (kib)
coordinates, such as digitizers and touch-screens, leaving these devices
to uhid(4) and user-level. Specially patched xf86-input-mouse driver can
handle them, that isn't done and can't be done properly with ums(4)
because of mouse(4) protocol limitations.
Approved by: re (kib)
Slot field of the PxCMD register may point to an empty command slot.
That breaks command timeout detection logic, making impossible to find
what command actually caused timeout, and leading to infinite wait.
Workaround that by checking whether pointed command slot is really used
and can timeout in its time. And if not, fallback to the dumb algorithm
used with FBS -- let all commands to time out and then fail all of them.
Approved by: re (kib)
MFC after: 1 week
the right SIM in case the HBA is RAID-capable but the target in question is
not a hot spare or member of a RAID volume.
- Report the loss and addition of SAS and SATA targets detected via PHY link
status changes and signalled by MPI_EVENT_SAS_DEVICE_STATUS_CHANGE to cam(4)
as lost devices and trigger rescans as appropriate. Without this it can take
quite some time until a lost device actually is no longer tried to be used,
if it ever stops. [1]
- Handle MPI_EVENT_IR2, MPI_EVENT_LOG_ENTRY_ADDED, MPI_EVENT_SAS_DISCOVERY
and MPI_EVENT_SAS_PHY_LINK_STATUS silently as these serve no additional
purpose beyond adding cryptic entries to logs.
Thanks to Hans-Joerg Sirtl for providing one of the HBAs these changes were
developed with and RIP to the mainboard that didn't survive testing them.
PR: 157534 [1]
Approved by: re (kib)
MFC after: 2 weeks
- Sprinkle some const where appropriate.
- Consistently use target_id_t for the target parameter of mpt_map_physdisk()
and mpt_is_raid_volume().
- Fix some whitespace bugs.
Approved by: re (kib)
accessing SATA registers. Unserialized access under heavy load caused
wrong speed reporting and potentially could cause device loss.
- To free memory and other resources (including above), allocated
during chipinit() method call on attach, add new chipdeinit() method,
called during driver detach.
Submitted by: Andrew Boyer <aboyer@averesystems.com> (initial version)
Approved by: re (kib)
MFC after: 1 week
Since no actual radar data is ever handled, this won't
do anything. It's mostly here as a reference for those who
wish to experiment with radar detection.
Approved by: re (kib)
the resource covers the entire range. Some BIOSes appear to mark
endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to
be used in _PRS when OSPM is allowed to allocate a certain chunk of
address space within a larger range, I don't believe it is supposed to be
used for _CRS).
Approved by: re (kib)
ioctl interface for DFS modules to use.
Since there's no open source dfs code yet, this doesn't introduce any
operational changes.
Approved by: re (kib)
tools.
* introduce pe_enabled, which (will) indicate whether the radar
detection stuff is enabled or not. Right now it's incorrectly
set, based on something previously written. I'll sort it out
later.
* Don't set HAL_PHYERR_PARAM_ENABLE in pe_relstep to say whether
radar detection is on.
* Return whether blockradar, fir128 and enmaxrssi is enabled.
* Change some of the phyerr params to be integers rather than
HAL_BOOL so they can be set to the NOPARAM value when the
setup function is called. This is in line with other radar
parameters.
* Add new configuration parameters for fir128, blockradar and
enmaxrssi, rather than defaulting to off, on and on respectively.
Approved by: re (kib)
polluting the AR5416 code with later chipset support.
Note: ar9280InitPLL() supports Merlin (AR9280) and later (AR9285, AR9287.)
Submitted by: ssgriffonuser@gmail.com
Approved by: re (kib)
These should be disabled for the AR5416 in hostap/mesh/ibss mode,
as the AR5416 doesn't have support for radar detection on the
ext channel of a HT40 setup. Later chips do.
Approved by: re (kib)
reference driver.
* Australia should use FCC3_WORLD
* Add some new SKUs; these are just the EEPROM values and haven't been
fully defined yet. As such they won't affect anything.
Obtained from: Atheros
Approved by: re (kib)
unknown reason Apple UniNorth2 gem(4) device required manual
interface down/up operation after r222135. Even though this is not
correct thing and I don't like to revert it but it would be better
than breaking gem(4) on PPC. This should be revisited.
PR: kern/157405
Back in 2009 I changed the ABI of the GIO_KEYMAP and PIO_KEYMAP ioctls
to support wide characters. I created a patch to add ABI compatibility
for the old calls, but I didn't get any feedback to that.
It seems now people are upgrading from 8 to 9 they experience this
issue, so add it anyway.
resource allocation on x86 platforms:
- Add a new helper API that Host-PCI bridge drivers can use to restrict
resource allocation requests to a set of address ranges for different
resource types.
- For the ACPI Host-PCI bridge driver, use Producer address range resources
in _CRS to enumerate valid address ranges for a given Host-PCI bridge.
This can be disabled by including "hostres" in the debug.acpi.disabled
tunable.
- For the MPTable Host-PCI bridge driver, use entries in the extended
MPTable to determine the valid address ranges for a given Host-PCI
bridge. This required adding code to parse extended table entries.
Similar to the new PCI-PCI bridge driver, these changes are only enabled
if the NEW_PCIB kernel option is enabled (which is enabled by default on
amd64 and i386).
Approved by: re (kib)
This was removed accidentally when the per HAL instance
code was added, and not reverted when I added back the
global debug variable (for early chip setup debugging.)
supports IPv4/IPv6 checksum offloading and VLAN tag insertion/
stripping as well as WOL. Because uether does not provide a way
to announce driver specific offload capabilities to upper stack,
checksum offloading support needs more work and will be done in
future.
Special thanks to ASIX for donating sample hardware.
H/W donated by: ASIX Electronics
Reviewed by: hselasky
system timer is stopped during shutdown and that the pause() statement in ukbd
causes infinite hang in this regard. The fix is to use mi_switch() instead of
pause() to do the required task switch to ensure that the required USB processes
get executed.
Reported by: Mike_Karels@mcafee.com
MFC after: 1 week
checking IFF_DRV_RUNNING and simplify the code. This also involves holding
the driver lock in the rx_ch callout.
- Just use ifp instead of sc->sc_ifp.
Submitted by: jhb (mostly)
allowing their use to be disabled via device hints though). This matches
what the corresponding Linux driver provided by LSI does. Tested with
SAS1064.
- There's no need to keep track of the RIDs used.
- Don't allocate MSI/MSI-X as RF_SHAREABLE.
- Remove a comment which no longer applies since r209599.
- Assign NULL rather than 0 to pointers.
MFC after: 1 month
bridge is blacklisted. In that case just return from pci_alloc_msix_method(),
otherwise we continue without a single MSI-X resource, causing subsequent
attempts to use the seemingly available resource to fail or when booting
verbose a NULL-pointer dereference of rle->start when trying to print the
IRQ in pci_alloc_msix_method().
Reviewed by: jhb
MFC after: 1 week
- Consistently use the newly introduced sc_mac_rxcfg throughout the driver
instead of reading the old content of CAS_MAC_RX_CONF.
- Increment if_iqdrops instead of if_ierrors in case of RX buffer allocation
failure.
- According to the Cassini datasheet the RX MAC should also be disabled in
cas_setladrf() before changing its configuration.
- Add error messages to gem_disable_{r,t}x() and take advantage of these
throughout the driver instead of duplicating their functionality all over
the place.
sets GEM_MAC_RX_CONFIG based on sc_mac_rxcfg which in turn is initialized
to zero, before reading the supposedly default configuration we were
effectively not basing sc_mac_rxcfg and thus GEM_MAC_RX_CONFIG on the
default configuration. Solve this by calling gem_setladrf() after reading
in the default configuration of GEM_MAC_RX_CONFIG. This also avoids the
need to distinguish whether gem_setladrf() should enable the RX MAC again
and should be slightly more correct as we're now doing all of the RX MAC
configuration in the intended step.
setting (either default or if supported as set by SIOCSIFFIB, e.g.
from ifconfig).
Submitted by: Alexander V. Chernikov (melifaro ipfw.ru)
Reviewed by: julian
MFC after: 2 weeks
em drivers.
- Make the per-instance 'enable_aim' sysctl truly per-instance by having it
change a per-instance variable (which is used to control AIM) rather
than having all of the per-instance sysctls operate on a single global
variable.
Reviewed by: jfv (earlier version)
MFC after: 1 week
the AP doesn't transmit beacons.
If the AP requests a CSA (ie, a channel switch) and then enters CAC
(channel availability check) for 60 seconds, it doesn't send beacons
and it just listens for radar events (and other things which we don't
do yet.)
Now, ath_newstate() was not resetting the beacon timer config on
a transition to the RUN state when in STA mode - it was setting
sc_syncbeacon, which simply updates the beacon config from the
contents of the next received beacon.
This means the STA never generates beacon miss events.
If the AP goes into CAC for 60 seconds and recovers, the STA will
happily receive the first beacon and reconfigure timers.
But if it gets a radar event after that, it'll change channel
again, not notify the station that it's changed channel..
and since the station is happily waiting for the first beacon
to configure the beacon timer details from, it won't ever
generate a beacon miss interrupt and it'll sit there forever
(or until the AP appears on that channel once again.)
This change forces the last known beacon timer config to be
written to hardware on a transition from CSA->RUN in STA mode.
This forces bmiss events to occur and the STA will eventually
(after a handful of beacon miss events) begin scanning for
another access point.
get it out of a stuck condition that can be caused by GEM_MAC_RX_OVERFLOW.
- In gem_reset_rxdma() call gem_setladrf() in order to reprogram the RX
filter and restore the previous content of GEM_MAC_RX_CONFIG. While at it
consistently use the newly introduced sc_mac_rxcfg throughout the driver
instead of reading the its old content.
- Increment if_iqdrops instead of if_ierrors in case of RX buffer allocation
failure.
- According to the GEM datasheet the RX MAC should also be disabled in
gem_setladrf() before changing its configuration.
- Add error messages to gem_disable_{r,t}x() and take advantage of these
throughout the driver instead of duplicating their functionality all over
the place.
In joint forces with: yongari
the microcode caused SCB timeouts. Linux driver does not allow
microcode loading for these controllers and jfv also confirmed that
there is no need to do and it shouldn't.
PR: kern/103332
Additional confirmation from: jfv
MFC after: 1 week
The DFS code was tickling the channel set directly whilst going
through the state RUN -> CSA -> RUN. This only changed the channel;
it didn't go via ath_reset(). However in this driver, a channel
change always causes a chip reset, which resets the beacon timer
configuration and interrupt setup. This meant that data would go
out but as the beacon timers never fired, beacons would never
be queued.
The confusing part is that sometimes the state transition was
RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes);
going via SCAN would clear sc_beacons and thus the transition
to RUN would reprogram beacon transmission.
In case someone tries debugging why suspending a device currently
beaconing (versus just RX'ing beacons which is what occurs in STA
mode), add a silly comment which should hopefully land them at
this commit message. The call to ath_hal_reset() will be clearing
the beacon config and it may not be always reset.
can be tested.
This doesn't at all actually do radar detection! It's just
so developers who wish to test the net80211 DFS code can easily
do so. Without this flag, the DFS channels are never marked
DFS and thus the DFS stuff doesn't run.
latter.
It appears that the addition to uath(4) came in through PR kern/135009,
which had tested another device, the SMCWUSBTG2, successfully with uath(4)
and included the SMCWUSBG as it "has the same chipset". I can find no
other evidence that these two do actually share the same chipset. Moreover,
Linux treats the SMCWUSBG as a zyd(4) device also.
This reverts r223537.
Discussed with: hselasky, kevlo
MFC after: 1 week
LED controller used to run the load graph on the server's front panel.
Reported by: Paul Mather <paul at gromit dot dlib dot vt dot edu>
MFC after: 3 days
dynamically loaded device drivers get a chance to run their event hooks.
- Decouple the USB suspend and resume lock from witness. It produces some
false warnings due to reusing the lock name among multiple devices.
MFC after: 3 days
is now required by bus_autoconf.
- Allow interface class matching even if device class is vendor specific.
- Update bus_autoconf tool to not generate system and subsystem match lines
for the nomatch event.
PR: misc/157903
MFC after: 14 days
sorted according to the mode which they support:
host, device or dual mode
- Add generic tool to extract these data:
tools/bus_autoconf
Discussed with: imp
Suggested by: Robert Millan <rmh@debian.org>
PR: misc/157903
MFC after: 14 days
to do about the few cases where the HAL state isn't available (regdomain)
or isn't yet setup (probe/attach.)
The global ath_hal_debug now affects all instances of the HAL.
This also restores the ability for probe/attach debugging to work; as
the sysctl tree may not be attached at that point. Users can just set
the global "hw.ath.hal.debug" to a suitable value to enable probe/attach
related debugging.
rather than global variables.
This specifically allows for debugging to be enabled per-NIC, rather
than globally.
Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.
The ALQ support is currently still global pending some brainstorming.
Submitted by: ssgriffonuser@gmail.com
Reviewed by: adrian, bschmidt
processors unless the invariant TSC bit of CPUID is set. Intel processors
may stop incrementing TSC when DPSLP# pin is asserted, according to Intel
processor manuals, i. e., TSC timecounter is useless if the processor can
enter deep sleep state (C3/C4). This problem was accidentally uncovered by
r222869, which increased timecounter quality of P-state invariant TSC, e.g.,
for Core2 Duo T5870 (Family 6, Model f) and Atom N270 (Family 6, Model 1c).
Reported by: Fabian Keil (freebsd-listen at fabiankeil dot de)
Ian FREISLICH (ianf at clue dot co dot za)
Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de)
- Core2 Duo T5870 (C3 state available/enabled)
jkim - Xeon X5150 (C3 state unavailable)
resource allocation from an x86 Host-PCI bridge driver so that it can be
reused by the ACPI Host-PCI bridge driver (and eventually the MPTable
Host-PCI bridge driver) instead of duplicating the same logic. Note that
this means that hw.acpi.host_mem_start is now replaced with the
hw.pci.host_mem_start tunable that was already used in the non-ACPI case.
This also removes hw.acpi.host_mem_start on ia64 where it was not
applicable (the implementation was very x86-specific).
While here, adjust the logic to apply the new start address on any
"wildcard" allocation even if that allocation comes from a subset of
the allowable address range.
Reviewed by: imp (1)
register both status change and link state change callbacks.
Implement checking valid link in state change callback and poll
active link state in vr_tick(). This allows immediate detection of
lost link as well as protecting driver from frequent link flips during
link renegotiation. taskq implementation was removed because driver
now needs to poll link state in vr_tick().
While I'm here do not report current link state if interface is not
running.
Tested by: n_hibma
MFC after: 1 week
o Consider No CIS a normal event and stop whining about it so much
(too many cards are like this, espeically usb/firewire cards).
o Add comments to the cis reading code.
o Made the read from config space a smidge easier to read and eliminate
a loop that can be done mathematically.
present. Only call the bus to check if we actually do timeout so we
don't affect the normal case (since this case needn't be optimized and
this guards against all races).
child is still present. If not, return 'handled' and don't print
anything (this is expected behavior). We expect an interrupt on eject,
power-down and/or shutdown.
particular flow control and dma coalesce. Also improve the
sysctl operation on those too.
Add IPv6 detection in the ioctl code, this was done for
ixgbe first, carrying that over.
Add resource ability to disable particular adapter.
Add HW TSO capability so vlans can make use of TSO
proceeding.
On boot, some laptops with certain cards in them sometimes fail on
boot, but if the card is inserted after boot it works. Experiments
show that small delays here makes things more reliable. It is
believed that some combinations need a little more time before the
power on the card is really stable enough to be reliable once the
power is stable in the bridge.
ACPI Device() objects that do not have any device IDs available via the
_HID or _CID methods. Without a device ID a device driver cannot attach
to the device anyway. Namespace objects that are devices but not of
type ACPI_TYPE_DEVICE are not affected.
A few BIOSes have also attached a _CRS method to a PCI device to
allocate resources that are not managed via a BAR. With the previous
code those resources are allocated from acpi0 directly which can interfere
with the new PCI-PCI bridge driver (since the PCI device in question may
be behind a bridge and its resources should be allocated from that
bridge's windows instead). The resources were also orphaned and
and would end up associated with some other random device whose device_t
reused the pointer of the original ACPI-enumerated device (after it was
free'd by the ACPI PCI bus driver) in devinfo output which was confusing.
If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus
driver to do that in the future and associate the resources with the
proper device object respecting PCI-PCI bridges, etc.
Note that with this change the ACPI PCI bus driver no longer has to
delete ACPI-enumerated device_t devices that mirror PCI devices since
they should in general not exist. There are rare cases when a BIOS
will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given
a _HID for a system resource device). In that case we leave both the
ACPI and PCI-enumerated device_t objects around just as in the previous
code.
method instead of reusing the existing per-queue interrupt task.
Reusing the per-queue interrupt task could result in both an interrupt
thread and the taskqueue thread trying to handle received packets on a
single queue resulting in out-of-order packet processing.
- Don't define igb_start() at all on 8.0 and where if_transmit is used.
Replace last remaining call to igb_start() with a loop to kick off
transmit on each queue instead.
- Call ether_ifdetach() earlier in igb_detach().
- Drain tasks and free taskqueues during igb_detach().
Reviewed by: jfv
MFC after: 1 week
announced during boot and contains the port number. The pnpinfo string
lists the port type (PUC_TYPE_* constants).
Tested by: Boris Samorodov bsam ipt ru
MFC after: 1 week
sys/dev/xen/blkback/blkback.c:
o Implement front-end request coalescing. This greatly improves the
performance of front-end clients that are unaware of the dynamic
request-size/number of requests negotiation available in the
FreeBSD backend driver. This required a large restructuring
in how this driver records in-flight transactions and how those
transactions are mapped into kernel KVA. For example, the driver
now includes a mini "KVA manager" that allocates ranges of
contiguous KVA to patches of requests that are physically
contiguous in the backing store so that a single bio or UIO
segment can be used to represent the I/O.
o Refuse to open any backend files or devices if the system
has yet to mount root. This avoids a panic.
o Properly handle "onlined" devices. An "onlined" backend
device stays attached to its backing store across front-end
disconnections. This feature is intended to reduce latency
when a front-end does a hand-off to another driver (e.g.
PV aware bootloader to OS kernel) or during a VM reboot.
o Harden the driver against a pathological/buggy front-end
by carefully vetting front-end XenStore data such as the
front-end state.
o Add sysctls that report the negotiated number of
segments per-request and the number of requests that
can be concurrently in flight.
Submitted by: kdm
Reviewed by: gibbs
Sponsored by: Spectra Logic Corporation
MFC after: 1 week
of the devices we manage. These changes can be due to writes
we make ourselves or due to changes made by the control domain.
The goal of these changes is to insure that all state transitions
can be detected regardless of their source and to allow common
device policies (e.g. "onlined" backend devices) to be centralized
in the XenBus bus code.
sys/xen/xenbus/xenbusvar.h:
sys/xen/xenbus/xenbus.c:
sys/xen/xenbus/xenbus_if.m:
Add a new method for XenBus drivers "localend_changed".
This method is invoked whenever a write is detected to
a device's XenBus tree. The default implementation of
this method is a no-op.
sys/xen/xenbus/xenbus_if.m:
sys/dev/xen/netfront/netfront.c:
sys/dev/xen/blkfront/blkfront.c:
sys/dev/xen/blkback/blkback.c:
Change the signature of the "otherend_changed" method.
This notification cannot fail, so it should return void.
sys/xen/xenbus/xenbusb_back.c:
Add "online" device handling to the XenBus Back Bus
support code. An online backend device remains active
after a front-end detaches as a reconnect is expected
to occur in the near future.
sys/xen/interface/io/xenbus.h:
Add comment block further explaining the meaning and
driver responsibilities associated with the XenBus
Closed state.
sys/xen/xenbus/xenbusb.c:
sys/xen/xenbus/xenbusb.h:
sys/xen/xenbus/xenbusb_back.c:
sys/xen/xenbus/xenbusb_front.c:
sys/xen/xenbus/xenbusb_if.m:
o Register a XenStore watch against the local XenBus tree
for all devices.
o Cache the string length of the path to our local tree.
o Allow the xenbus front and back drivers to hook/filter both
local and otherend watch processing.
o Update the device ivar version of "state" when we detect
a XenStore update of that node.
sys/dev/xen/control/control.c:
sys/xen/xenbus/xenbus.c:
sys/xen/xenbus/xenbusb.c:
sys/xen/xenbus/xenbusb.h:
sys/xen/xenbus/xenbusvar.h:
sys/xen/xenstore/xenstorevar.h:
Allow clients of the XenStore watch mechanism to attach
a single uintptr_t worth of client data to the watch.
This removes the need to carefully place client watch
data within enclosing objects so that a cast or offsetof
calculation can be used to convert from watch to enclosing
object.
Sponsored by: Spectra Logic Corporation
MFC after: 1 week
- Fix races on setting AAC_AIFFLAGS_ALLOCFIBS
- Remove some unused AAC_IFFLAGS_* bits.
Please note that the kthread still makes a difference between the
total mask and AAC_AIFFLAGS_ALLOCFIBS because more flags may be
added in the future to aifflags.
Sponsored by: Sandvine Incorporated
Reported and reviewed by: emaste
MFC after: 2 weeks
but has only 2 SATA ports instead of 4. The worst part is that SStatus and
SError registers for missing ports are not implemented and return wrong
values (0xffffffff), that caused infinite reset loop.
Just ignore that SError value while I found no better way to identify them.
increase robustness (no more calls to panic(9)) and simplify
code.
- Allocate RX/TX data structures as a single buffer rather than
an array of 4KB pages to simplify code.
- Fixed LRO (aka TPA) code. Removed kernel module parameter and
support enabling disabling LRO through ifconfig(8) command line.
LRO is still disabled by default but should be enabled for best
performance on an endpoint device.
- Fixed statistcs code and removed kernel module parameter (stats
should just work).
- Added many software counters to help identify the cause of some
performance issues.
- Streamlined adapter internal init/stop code paths.
- Fiddled with debug code (adding some here, removing some there).
- Continued style(9) adjustments.
- Add retry loops in the i2c read/write functions.
- Combied the ADC channel selection and readout of the value into
one iicbus_transfer to avoid possible races.
Reviewed by: nwhitehorn
of just setting it to the first registered device, reevaluate it for each
device registered, trying to choose best candidate, unless one was forced.
For now use such preference order: play&rec, play, rec.
As side effect, this should workaround the situation when HDMI audio output
of the video card, usually not connected to anything, becomes default, that
requires manual user intervention to make sound working. If at some point
this won't be enough, we can try to fetch some additional priority flags
from the device driver.
For the AR5211/AR5212, this is apparently a one byte pulse duration
counter value. It is only coded up here for the AR5212 as I don't have
any AR5211-series hardware to test it on.
This information was extracted from the Madwifi DFS branch along with
some local additions.
Please note - all this does is extract out the radar event duration,
it in no way reflects the presence of a radar. Further code is needed
to take a set of radar events and filter them to extract out correct
radar pulse trains (and ignore other events.)
For further information, please see:
http://wiki.freebsd.org/dev/ath_hal%284%29/RadarDetection
This includes references to the relevant patents which describe what
is going on.
Obtained from: Madwifi
Many thanks to Tino <tinotom@gmail.com> for drawing my attention to
this, for doing a lot of testing and providing great feedback.
Many thanks to AMD for continuing to release public specifications for
their chipsets.
PR: kern/157568
Tested by: Tino <tinotom@gmail.com>
MFC after: 1 week
points are fixed addresses and (U)EFI CSM specification also mandated that.
Unfortunately, (U)EFI CSM specification does not specifically mention this
is to call service routine via interrupt vector table or to jump directly
to the entry point. As a result, some CSM seems to install two routines
and acts differently, depending on how it was executed, unfortunately.
When INT 15h is used, it calls a function pointer (which is probably a UEFI
service function). When it jumps directly to the entry point, it executes
a simple and traditional INT 15h service routine. Therefore, actually there
are two possible fixes, i. e., this fix or jumping directly to the fixed
entry point. However, we chose this fix because a) keyboard typematic
support via BIOS is becoming extremely rarer and b) we cannot support random
service routine installed by a firmware or a boot loader. This should fix
Lenovo X220 laptop, specifically.
Reviewed by: delphij
MFC after: 3 days
High-speed USB HUB by resetting the transaction translator (TT)
before trying re-enumeration. Also when clear-stall fails multiple times
try a re-enumeration.
Suggested by: Trevor Blackwell
MFC after: 14 days
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Instead, change this so
that it recognizes this case and only adds it once and do not delete the
BAR outright after parsing the CIS.
Tested by: bschmidt
probe requests at 1Mbps while being associated on a 5GHz channel. Sending
those at 6Mbps does work, so use that instead during a background scan.
This workaround allows us to re-enable background scan support for the
4965 adapters.
Also, just enabling one antenna on 5GHz results in better reception of
beacons:
test 00:26:5a:c6:14:1a 40 54M -71:-95 200 E WME HTCAP ATH
vs
test 00:26:5a:c6:14:1a 40 54M -92:-95 200 E WME HTCAP ATH
Due to roam:rssi thresholds set to 7 by default it might have been
impossible to associate to that network. While here use
IEEE80211_IS_CHAN_5GHZ() to determine the band.
- Add a retry loop for the i2c sensor reading.
- Check on busy status of the chip and on invalid values.
- Fix a typo in a comment.
- Replace the constant 2732 with the ZERO_C_TO_K macro.
Approved by: nwhitehorn (mentor)
module.
* If sc->sc_dodfs is set to 1 by the ath_dfs_radar_enable(),
set the relevant rx filter bit to begin receiving radar PHY
errors. The HAL code already knows how to set the relevant
error mask register to enable radar events.
* Add a missing call to ath_dfs_radar_enable() after ath_hal_reset()
* change ath_dfs_process_phyerr() to take a const char *buf for now,
rather than a descriptor. This way it can get access to the packet
buffer contents.
real owner of the device ID. Also rename the associated config
function while here.
- Add support for the 2-port and 4-port Exar parts as well: Exar XR17C/D152
and Exar XR17C154.
Tested by: Mike Tancsa, Willy Offermans Willy of offermans rompen nl
MFC after: 1 week
- Add a retry loop for the i2c sensor reading.
- Update the sensor handling for sensors which do not have a location
entry. [1]
Submitted by: [1] Justin Hibbits.
Approved by: nwhitehorn (mentor)
These cause problems when trying to include the header in a C++ project.
Rename them to 'evt_class', and track the change in mfi and mfiutil.
Submitted by: Mark Johnston
Sponsored by: Sandvine Incorporated
Reviewed by: jhb@
MFC after: 1 week
crusty, and this still isn't perfect, but its at least a bit
more recent.
Secondly, a few improvements to the driver from Andrew Boyer,
support hint to allow devices to not attach, add VLAN_HWTSO
capability so vlans can use TSO, fix in the interrupt handler
to make sure the stack TX queue is processed. Oh, and also
make sure IPv6 does not cause a re-init in the ioctl routine.
Thanks for your efforts Andrew!
Thanks to Claudio Jeker for noticing the ixgbe_xmit() routine
was not correctly swapping the dma map from the first to the
last descriptor in a multi-descriptor transmission, corrected
this.
This is in no way a complete DFS/radar detection implementation!
It merely creates an abstracted interface which allows for future
development of the DFS radar detection code.
Note: Net80211 already handles the bulk of the DFS machinery,
all we need to do here is figure out that a radar event has occured
and inform it as such. It then drives the DFS state engine for us.
The "null" DFS radar detection module is included by default;
it doesn't require a device line.
This commit:
* Adds a simple abstracted layer for radar detection state -
sys/dev/ath/ath_dfs/;
* Implements a null DFS module which doesn't do anything;
(ie, implements the exact behaviour at the moment);
* Adds hooks to the ath driver to process received radar events
and gives the DFS module a chance to determine whether
a radar has been detected.
Obtained from: Atheros
Please note - this doesn't in any way constitute a full DFS
implementation, it merely adds the relevant capability bits and
radar detection threshold register access.
The particulars:
* Add new capability bits outlining what the DFS capabilities
are of the various chipsets.
* Add HAL methods to set and get the radar related register values.
* Add AR5212 and AR5416+ DFS radar related register value
routines.
* Add a missing HAL phy error code that's related to radar event
processing.
* Add HAL_PHYERR_PARAM, a data type that encapsulates the radar
register values.
The AR5212 routines are just for completeness. The AR5416 routines
are a super-set of those; I may later on do a drive-by pass to
tidy up duplicate code.
Obtained from: Linux, Atheros
The version is used to check if a module is already preset, not setting
it results in:
can't re-use a leaf (ipw)!
module_register: module pci/ipw already exists!
Module pci/ipw failed to register: 17
while trying to load the module due to an entry in loader.conf. With this
commit we get the expected:
module ipw already present!
Reported by: Dru Lavigne, bz
Tested by: bz
MFC after: 1 week
process received frames. Previously it was possible to handle RX
interrupts even if controller is not fully initialized. This
resulted in non-working driver after system is up and running.
Reported by: hselasky
Tested by: hselasky
queues. Try to have a set of these per port when possible, fall back
to sharing a common pool between all ports otherwise.
- One control queue per port (used to be one per hardware channel).
- t4_eth_rx now handles Ethernet rx only.
- sysctls to display pidx/cidx for some queues.
MFC after: 1 week
filters working. (All other filters - switch without L2 info rewrite,
steer, and drop - were already fully-functional).
Some contrived examples of "switch" filters with L2 rewriting:
# cxgbetool t4nex0 iport 0 dport 80 action switch vlan +9 eport 3
Intercept all packets received on physical port 0 with TCP port 80 as
destination, insert a vlan tag with VID 9, and send them out of port 3.
# cxgbetool t4nex0 sip 192.168.1.1/32 ivlan 5 action switch \
vlan =9 smac aa:bb:cc:dd:ee:ff eport 0
Intercept all packets (received on any port) with source IP address
192.168.1.1 and VLAN id 5, rewrite the VLAN id to 9, rewrite source mac
to aa:bb:cc:dd:ee:ff, and send it out of port 0.
MFC after: 1 week
hardware supports it.
Since ni->ni_htcap in hostap mode is what the remote end has advertised,
not what has been negotiated/decided, we need to check ourselves what
the current channel width is and what the hardware supports before
enabling short-GI.
It's important that short-GI isn't enabled when it isn't negotiated
and when the hardware doesn't support it (ie, short-gi for 20mhz channels
on any chip < AR9287.)
I've quickly verified this on the AR9285 in 11n mode.
1. Both mmc_read_ivar() and sdhci_read_ivar() use the expression
'*(int *)result = val' to assign to result which is uintptr_t *.
This does not work on big-endian 64 bit systems.
2. The media_size ivar is declared as 'off_t' which does not fit
into uintptr_t in 32bit systems, change this to long.
Submitted by: kanthms at netlogicmicro com (initial version)
This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.
which uses a non-standard clock (* 8) while any additional ports use
SUN1699 chips which use a standard clock.
Tested by: N.J. Mann njm of njm me uk
MFC after: 1 week
MCR register on the Sunix Sun1699 chip tends to be set but doesn't
seem to have a function. That is, FreeBSD just works (provided the
correct RCLK is used) regardless.
PR: kern/129663
Diagnostics: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
MFC after: 3 days
AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left
the 5ghz edge flags in there for now) and hard-coded the 2ghz-only
path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g,
matching the rest of my 11g kit.
I'm assuming for now that the AR9287 is only open-loop TX power control
(as mine is) so I've hard-coded the attach path to fail if the NIC is
not open-loop.
This greatly simplifies the TX calibration path and the amount of code
which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be
ported and it all needs to be glued together.
Obtained from: Linux ath9k
without waiting for device readiness (or at least not updating FIS receive
area in time). To workaround that, special quirk was added earlier to wait
for the FIS receive area update. But it was found that under same PCI ID
0x91231b4b and revision 0x11 there are two completely different chip
versions (firmware?): HBA and RAID. The problem is that RAID version in
some cases, such as hot-plug, does not update FIS receive area at all!
To workaround that, differentiate the chip versions by their capabilities,
and, if RAID version found, skip FIS receive area update waiting and read
device signature from the PxSIG register instead. This method doesn't work
for HBA version when PMP attached, so keep using previous workaround there.
It isn't linked into the build because it's missing the TX power
and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against
the Atheros codebase as appropriate.
What's implemented:
* probe/attach
* EEPROM board value programming
* RX initial calibration
* radio channel programming
* general MAC / baseband setup
* async fifo setup
* open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code
* closed-loop tx power calibration routines
* TSF2 handling
* generic timer support from ath9k
Obtained from: Atheros, ath9k
(SEMB) is unable to communicate to Storage Enclosure Processor (SEP), in
response to hard and soft resets it should among other things return value
0x7F in Status register. The weird side is that it means DRQ bit set, which
tells that reset request is not completed. It would be fine if SEMB was the
only device on port. But if SEMB connected to PMP or built into it, it may
block access to other devices sharing same SATA port.
Make some tunings/fixes to soft-reset handling to workaround the issue:
- ahci(4): request CLO on the port after soft reset to ignore DRQ bit;
- siis(4): gracefully reinitialize port after soft reset timeout (hardware
doesn't detect reset request completion in this case);
- mvs(4): if PMP is used, send dummy soft-reset to the PMP port to make it
clear DRQ bit for us.
For now this makes quirks in ata_pmp.c, hiding SEMB ports of SiI3726/SiI4726
PMPs, less important. Further, if hardware permit, I hope to implement real
SEMB support.
values for the commands, compared to the internal command values
(HAL_ANI_CMD.)
My eventual aim is to make the HAL_ANI_CMD internal enum match
the public API and then remove all this messiness.
This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_
enum rather than magic constants.
The only magic constants currently used by if_ath are "enable" and
"present". Some local tools of mine allow for direct, manual fiddling
of the ANI variables and I'll convert these to use the public enum API
before I commit them.
of the ANI statistics and committing some tools which use these.
* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.
which did AR5212 specific initialisation. This would cause some slight
silliness when enabling/disabling ANI.
Just to be completely correct - and to ensure the phy error mask/RX filter
register isn't incorrectly played with - make the ANI control function a
method, have it set appropriately for AR5212/AR5416, and call that from the
ANI control interface.
This should hopefully make it clearer to developers what is going on
and when TPC is being hacked on, make it obvious why it isn't working for
series 1, 2, 3.
I won't flip on setting TX power for TX series 1, 2, 3 until I've done
some further testing with Kite to ensure it doesn't break anything.
(Before people ask - yes, TPC is only needed for 5ghz regdomains and
yes, Kite is a 2.4ghz only chip, but there are potential use cases
for 2ghz TPC. I just need to sit down and ensure it's supported and
functional.)
control the antenna control bits for the four TX series and the
TPC settings for TX series 1, 2, 3.
The specifics:
* The TPC setting for TX series 0 is handled in ctl0.
* TPC is currently disabled, so the per-packet TX power is
set via the global per-rate TX power register, not per packet.
* The antenna control bits don't matter for AR5416 and later
so they should stay 0 (which they currently do); they may
be set for Kite but as there's no TX diversity supported
at the moment (it requires the NIC to be built with an
external antenna switch, matching how antenna diversity
is done on legacy NICs), so again keep them 0.
This is in preparation for supporting per-rate TPC on the
AR5416 and later. The Kite (and soon to come Kiwi) code
sets ctl8-11 to 0x0, which doesn't have any effect at
the moment. When TPC is enabled it would result in the
second, third and fourth TX series attmpts to be done with
a TX power of 0. This commit doesn't change that; it'll
be followed up with some commits to properly set the TPC
registers appropriately.
quality to 950. HPET on modern platforms usually have better resolution and
lower latency than ACPI timer. Effectively this changes default timecounter
hardware from ACPI-fast to HPET by default when both are available.
Discussed with: avg
bits of the register is used for other purposes such that clearing
these bits resulted in unexpected results such as corrupted RX
frames or missing LE status updates. For old controllers like
Yukon EC it had no effect but it caused all kind of troubles on
Yukon Supreme.
This change shall improve stability of controllers like Yukon
Ultra, Ultra2, Extreme, Optima and Supreme.
Rewrite atomic operations for powerpc in order to achieve the following:
- Produce a type-clean implementation (in terms of functions arguments
and returned values) for the primitives.
- Fix errors with _long() atomics where they ended up with the wrong
arguments to be accepted.
- Follow the sys/type.h specifics that define the numbered types starting
from standard C types.
- Let _ptr() version to not auto-magically cast arguments, but leave
the burden on callers, as _ptr() atomic is intended to be used
relatively rarely.
Fix cfi in order to support the latest point.
In collabouration with: bde
Tested by: andreast, nwhitehorn, jceel
MFC after: 2 weeks
which is now disabled by default. The detection is known to cause hangs
on boot with some new Lenovo laptops on FreeBSD/amd64.
Reported by: gnn
Discussed with: jkim
MFC after: 3 months
not true on old PCI based controllers. DAC configuration is read
from EEPROM in device reset phase and driver can override DAC
configuration. However I guess there is an undocumented reason why
EEPROM configuration does not enable DAC so do not blindly override
DAC configuration. Recent PCIe based controllers are supposed to
support 64bit DMA so allow 64bit DMA only on PCIe based controllers.
PR: kern/157184
MFC after: 1 week
IFF_DRV_RUNNING flag. Previously running dhclient or adding alias
addresses reinitialized controller and it resulted in unnecessary
link flips.
Reviewed by: marius
Oxford Semiconductor OX16PCI954 but uses only two ports with a non-default
clock rate.
PR: kern/152034
Tested by: Hans Fiedler hans of hermes louisville edu
MFC after: 1 week
This brings USB bus more in line with how newbus is supposed to be used.
Also, because of the two-pass probing the following message was produced
by devd in default configuration when almost any USB device was
connected:
Unknown USB device: vendor <> product <> bus <>
This should be fixed now.
Note that many USB device drivers pass some information from probe
method to attach method via ivars. For this to continue working we rely
on the fact that the subr_bus code calls probe method of a winning driver
again before calling its attach method in the case where multiple
drivers claim to support a device. This is done because device
description is set in successful probe methods and we want to get a correct
device description from a winning driver. So now this logic is re-used
for setting ivars too.
Reviewed by: hselasky
MFC after: 1 month
When supported by hardware, this allows to control per-port activity, locate
and fault LEDs via the led(4) API for localization and status reporting
purposes. Supporting AHCI controllers may transmit that information to the
backplane controllers via SGPIO interface. Backplane controllers interpret
received statuses in some way (IBPI standard) to report them using present
indicators.
the multicast key search support for AR5212, AR5416 and later.
The general HAL routine ath_hal_getcapability() implement checking this
but it's overridden by a check in ar5212_misc:ar5212GetCapability().
This restores the later functionality in case it's found to be broken
in any of the 11n chipsets.
The other queues, especially the command queue, uses the FIFO mode
which doesn't require the byte count table because queued entries are
processed in order.
Pointed out by: Lucius Windschuh <lwindschuh at googlemail dot com>
Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.
The eeprom Get method should return HAL_OK if fastclock is enabled in the
EEPROM. It was returning the opposite of what it should have.
Submitted by: Matthew Fleming <mdf356@gmail.com>
The code assumed it could return HAL_OK, HAL_EINVAL and other
HAL_STATUS types; so it shouldn't be declared as returning HAL_BOOL.
This commit was brought to you by the Clang compiler.
Submitted by: Matthew Fleming <mdf356@gmail.com>
I've tested this locally and it does indeed read and attach to an AR9287
EEPROM. But a lot more code needs to be ported over to the HAL before
the AR9287 is functional.
I'm importing this separate from the rest of the codebase (and unlinked from
the build for now) in case someone wishes to begin fiddling with porting
the rest of the code over from Linux ath9k.
Obtained from: Linux ath9k
is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where
RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with
the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
architectures (i386, for example) the virtual memory space may be
constrained enough that 2MB is a large chunk. Use 64K for arches
other than amd64 and ia64, with special handling for sparc64 due to
differing hardware.
Also commit the comment changes to kmem_init_zero_region() that I
missed due to not saving the file. (Darn the unfamiliar development
environment).
Arch maintainers, please feel free to adjust ZERO_REGION_SIZE as you
see fit.
Requested by: alc
MFC after: 1 week
MFC with: r221853
that for _ptr operations, when not used directly with uintptr_t, we
needed to manually cast.
Use the cast on the _ptr version, where it actually wasn't (please note
that i386 doesn't get it right, while amd64 doesn't seem to compile
cfi neither in LINT, that is why it doesn't fail).
Reported by: sbruno
for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.
table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160,
AR9280) and will also be used by the upcoming Kite (AR9287) support.
* grab the main, alt and selected LNA config
* add some optional / disabled logging code
* add a check to reject packets with an invalid main rssi too,
in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
- Use bus_bind_intr() to bind interrupt to a CPU when RSS/TSS is used.
- Use M_DONTWAIT for RSS/TSS buffer allocation.
- Add statistic to track max DRBR queue depth.
- Fix problem in bxe_change_mtu() which referenced the old MTU size
in a debug print statement.
MFC after: Two weeks
disabled for BCM5719 A0 revision due to known hardware errata.
Many thanks to Broadcom for continuing support of FreeBSD.
Submitted by: Geans Pin at Broadcom
AR8132 FastEthernet controller. The PHY has no ability to
establish a gigabit link. Previously only link parters which
support down-shifting was able to establish link.
This change should fix a long standing link establishment issue of
AR8132.
PR: kern/156935
MFC after: 1 week
Casting a pointer to a wide integer is probably not that bad, but I am
still guilty of not testing this.
Pointyhat to: avg
MFC after: 1 week
X-MFC with: r221803
This brings our implementation in line with OSS specification for
systems that support mmap. The change should also improve compatibility
with OSS software not specifically written for FreeBSD, e.g. PulseAudio
OSS plugin.
Reviewed by: kib, jhb
MFC after: 1 week
environments.
In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).
Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.
Obtained from: Atheros, ath9k, my local HAL
This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).
Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.
The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.
* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.
Obtained from: Atheros
newer controllers. However, all data sheet I have access has no
indication that buffer manager should not be touched on these
controllers. It seems the buffer manager always runs on BCM5705 or
newer controllers. Some controller(e.g. BCM5719) needs other buffer
manager configuration so driver should enable buffer manager for
all controllers. Both Linux and OpenBSD/NetBSD use the same
approach.
This change polls enable bit of block to know whether specified
block was really stopped as well as enabling buffer manager for all
controllers in driver initialization.
Obtained from: NetBSD
from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite
a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.
Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..
Obtained from: Atheros
The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std
On legacy channels every once in a while the firmware throws a SYSASSERT
on line 208. On HT channels though this does always happen and I'm not
aware of any workaround currently.
for the given channel is available.
It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.
specific.
The Atheros HAL and FreeBSD HAL share the same capabilities up
until HAL_CAP_11D, where things begin to diverge.
I'll look at tidying these up soon.
Obtained from: Atheros
* Add Howl (ar9130) to the list of chips that have DFS/BB/MAC hangs
* Don't treat unknown BB hangs as fatal; ath9k/Atheros HAL don't
treat it as such.
* Add HAL_DEBUG_DFS to the debug fields in ath_hal/ah_debug.h
The BB hang check simply loops over an observation register checking
for a stuck state engine, but it can happen under high traffic
conditions. Ath9k and the Atheros HAL simply log a debug message and
continue.
Private to FreeBSD:
* Add HAL_DEBUG_HANG to the debug fields
* Change the hang debugging to HAL_DEBUG_HANG rather than HAL_DEBUG_DFS
like in the Atheros HAL.
Obtained from: Atheros
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER
will later change to exclude Howl (AR9130) in line with what
the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
A quick story, which is partially documented in the commit.
The silicon revision in Linux ath9k and the Atheros HAL use an
AR_SREV_REVISION mask of 0x07.
FreeBSD's HAL uses the AR5212 AR_SREV_REVISION mask of 0x0F.
Thus the OWL silicon revisions were coming through as 0xA, 0xB,
0xC, rather than 0x0, 0x1 and 0x2.
My ath9k-sourced AR_SREV_OWL_<X> macros were thus using the wrong
silicon revision values and wouldn't correctly match.
This commit does a few things:
* Change the AR_SREV_OWL_<x> macros to use the AR_SREV_REVISION_OWL_*
values, not AR_XSREV_REVISION_OWL macros;
* Disable AR_XSREV_REVISION_OWL_* values;
* Modify the IS_5416 to properly check the MAC is OWL, rather than
potentially matching on non-OWL revisions (which shouldn't happen
unless there's a silicon revision of higher than 0x9 in a later
chip..)
* Add a couple more macros from the Atheros HAL for compatibility.
The main difference now is that the Atheros HAL defines
AR_SREV_OWL_{20,22}_OR_LATER subtly differently - it fails on all HOWL
silicon. The AR_SREV_5416_*_OR_LATER macros match on the relevant OWL
version -and- all HOWL versions, along with subsequent versions.
A subsequent commit is going to migrate the uses of AR_SREV_OWL_X_OR_LATER
to AR_SREV_5416_X_OR_LATER to match what's going on in the Atheros HAL.
There's only two uses of AR_SREV_OWL_X_OR_LATER which currently don't
apply to FreeBSD but it may do in the future.
Yes, it's all confusing!
tick driving logic to xl_tick(). Now xl_tick() handles MII tick as
well as periodic updating of statistics.
This change removes a hack used in interrupt handler where it
wanted to update statistics without driving MII tick.
picking the next available one. This may explain why xl(4) sees TX
underrun error with no queued frame. I hope this addresses a long
standing xl(4) watchdog timeout issue as well.
Obtained from: OpenBSD
RX descriptor ring. Previously it returned the number of frames
that were successfully passed to upper stack which in turn means it
ignored frames that were discarded due to errors. The number of
processed frames in RX descriptor ring is used to detect whether
driver is out of sync with controller's current descriptor pointer.
Returning number of processed frames reduces unnecessary (probably
wrong) re-synchronization.
While here, remove unnecessary local variable initialization.
handler for 3C90x and 3C90xB/C respectively. This simplifies ioctl
handler as well as enhancing readability.
While I'm here don't reprogram multicast filter when driver is not
running.
this there is a rare return path that bogusly appears
to fail when it should not. Also white space correction.
Thanks to Arnaud Lacombe for noticing the problem.
cpuset_t objects.
That is going to offer the underlying support for a simple bump of
MAXCPU and then support for number of cpus > 32 (as it is today).
Right now, cpumask_t is an int, 32 bits on all our supported architecture.
cpumask_t on the other side is implemented as an array of longs, and
easilly extendible by definition.
The architectures touched by this commit are the following:
- amd64
- i386
- pc98
- arm
- ia64
- XEN
while the others are still missing.
Userland is believed to be fully converted with the changes contained
here.
Some technical notes:
- This commit may be considered an ABI nop for all the architectures
different from amd64 and ia64 (and sparc64 in the future)
- per-cpu members, which are now converted to cpuset_t, needs to be
accessed avoiding migration, because the size of cpuset_t should be
considered unknown
- size of cpuset_t objects is different from kernel and userland (this is
primirally done in order to leave some more space in userland to cope
with KBI extensions). If you need to access kernel cpuset_t from the
userland please refer to example in this patch on how to do that
correctly (kgdb may be a good source, for example).
- Support for other architectures is going to be added soon
- Only MAXCPU for amd64 is bumped now
The patch has been tested by sbruno and Nicholas Esborn on opteron
4 x 12 pack CPUs. More testing on big SMP is expected to came soon.
pluknet tested the patch with his 8-ways on both amd64 and i386.
Tested by: pluknet, sbruno, gianni, Nicholas Esborn
Reviewed by: jeff, jhb, sbruno
Quoting the ath9k commit message:
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Reference: https://patchwork.kernel.org/patch/753862/
Obtained from: Linux ath9k
The checks should function as follows:
* AR_SREV_<silicon> : check macVersion matches that version id
* AR_SREV_<silicon>_<revision> : check macVersion and macRevision match
the version / revision respectively
* AR_SREV_<silicon>_<revision>_OR_LATER: check that
+ if the chip silicon version == macVersion, enforce revision >= macRevision
+ if the chip silicon version > macVersion, allow it.
For example, AR_SREV_MERLIN() only matches AR9280 (any revision),
AR_SREV_MERLIN_10() would only match AR9280 version 1.0, but
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 version >= 2.0 _AND_
any subsequent MAC (So AR9285, AR9287, etc.)
The specific fixes which may impact users:
* if there is Merlin hardware > revision 2.0, it'll now be correctly
matched by AR_SREV_MERLIN_20_OR_LATER() - the older code simply
would match on either Merlin 2.0 or a subsequent MAC (AR9285, AR9287, etc.)
* Kite version 1.1/1.2 should now correctly match. As these macros
are used in the AR9285 reset/attach path, and it's assumed that the
hardware is kite anyway, the behaviour shouldn't change. It'll only
change if these macros are used in other codepaths shared with
older silicon.
Obtained from: Linux ath9k, Atheros
Reference code that shows how to get a packet's timestamp out of
cxgbe(4). Disabled by default because we don't have a standard way
today to pass this information up the stack.
The timestamp is 60 bits wide and each increment represents 1 tick of
the T4's core clock. As an example, the timestamp granularity is ~4.4ns
for this card:
# sysctl dev.t4nex.0.core_clock
dev.t4nex.0.core_clock: 228125
MFC after: 1 week
- Enable 5-tuple and every-packet lookup.
- Setup the default filter mode to allow filtering/steering based on IP
protocol, ingress port, inner VLAN ID, IP frag, FCoE, and MPS match
type; all combined together. You can also filter based on MAC index,
Ethernet type, IP TOS/IPv6 Traffic Class, and outer VLAN ID but you'll
have to modify the default filter mode and exclude some of the
match-fields in it.
IPv4 and IPv6 SIP/DIP/SPORT/DPORT are always available in all filter
rules.
- Add driver ioctls to get/set the global filter mode.
- Add driver ioctls to program and delete hardware filters. A couple of
the "switch" actions that rewrite Ethernet and VLAN information and
switch the packet out of another port may not work as the L2 code is not
yet in place. Everything else, including all "drop" and "pass" rules
with RSS or absolute qid, should work.
Obtained from: Chelsio Communications
have similar hardware features of BCM5718 family except the number
of receive return ring is 4. The BCM57765 family is known to
support IEEE 802.3az EEE(Energy Efficient Ethernet) but this change
does not include EEE support code. I hope EEE is implemented in
near future.
This change will support BCM57761, BCM57765, BCM57781, BCM57785,
BCM57791 and BCM57795. All hardware offloading features are
supported and suspend/resume also should work.
Many thanks to Broadcom for continuing support of FreeBSD.
Tested by: Paul Thornton (prt <> prt dot org)
HW donated by: Broadcom
(reporting IFM_LOOP based on BMCR_LOOP is left in place though as
it might provide useful for debugging). For most mii(4) drivers it
was unclear whether the PHYs driven by them actually support
loopback or not. Moreover, typically loopback mode also needs to
be activated on the MAC, which none of the Ethernet drivers using
mii(4) implements. Given that loopback media has no real use (and
obviously hardly had a chance to actually work) besides for driver
development (which just loopback mode should be sufficient for
though, i.e one doesn't necessary need support for loopback media)
support for it is just dropped as both NetBSD and OpenBSD already
did quite some time ago.
- Let mii_phy_add_media() also announce the support of IFM_NONE.
- Restructure the PHY entry points to use a structure of entry points
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for lxtphy(4) which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
This includes changing NIC drivers which previously just called the
generic mii_phy_reset() to now actually call the PHY-specific reset
routine, which might be crucial in some cases. While at it, the
redundant checks in these NIC drivers for mii->mii_instance not being
zero before calling the reset routines were removed because as soon
as one PHY driver attaches mii->mii_instance is incremented and we
hardly can end up in their media change callbacks etc if no PHY driver
has attached as mii_attach() would have failed in that case and not
attach a miibus(4) instance.
Consequently, NIC drivers now no longer should call mii_phy_reset()
directly, so it was removed from EXPORT_SYMS.
- Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe().
The purpose of that function is to perform the common steps to attach
a PHY driver instance and to hook it up to the miibus(4) instance and to
optionally also handle the probing, addition and initialization of the
supported media. So all a PHY driver without any special requirements
has to do in its bus attach method is to call mii_phy_dev_attach()
along with PHY-specific MIIF_* flags, a pointer to its PHY functions
and the add_media set to one. All PHY drivers were updated to take
advantage of mii_phy_dev_attach() as appropriate. Along with these
changes the capability mask was added to the mii_softc structure so
PHY drivers taking advantage of mii_phy_dev_attach() but still
handling media on their own do not need to fiddle with the MII attach
arguments anyway.
- Keep track of the PHY offset in the mii_softc structure. This is done
for compatibility with NetBSD/OpenBSD.
- Keep track of the PHY's OUI, model and revision in the mii_softc
structure. Several PHY drivers require this information also after
attaching and previously had to wrap their own softc around mii_softc.
NetBSD/OpenBSD also keep track of the model and revision on their
mii_softc structure. All PHY drivers were updated to take advantage
as appropriate.
- Convert the mebers of the MII data structure to unsigned where
appropriate. This is partly inspired by NetBSD/OpenBSD.
- According to IEEE 802.3-2002 the bits actually have to be reversed
when mapping an OUI to the MII ID registers. All PHY drivers and
miidevs where changed as necessary. Actually this now again allows to
largely share miidevs with NetBSD, which fixed this problem already
9 years ago. Consequently miidevs was synced as far as possible.
- Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that
weren't explicitly converted to support flow control before. It's
unclear whether flow control actually works with these but typically
it should and their net behavior should be more correct with these
changes in place than without if the MAC driver sets MIIF_DOPAUSE.
Obtained from: NetBSD (partially)
Reviewed by: yongari (earlier version), silence on arch@ and net@
driver would verify that requests for child devices were confined to any
existing I/O windows, but the driver relied on the firmware to initialize
the windows and would never grow the windows for new requests. Now the
driver actively manages the I/O windows.
This is implemented by allocating a bus resource for each I/O window from
the parent PCI bus and suballocating that resource to child devices. The
suballocations are managed by creating an rman for each I/O window. The
suballocated resources are mapped by passing the bus_activate_resource()
call up to the parent PCI bus. Windows are grown when needed by using
bus_adjust_resource() to adjust the resource allocated from the parent PCI
bus. If the adjust request succeeds, the window is adjusted and the
suballocation request for the child device is retried.
When growing a window, the rman_first_free_region() and
rman_last_free_region() routines are used to determine if the front or
end of the existing I/O window is free. From using that, the smallest
ranges that need to be added to either the front or back of the window
are computed. The driver will first try to grow the window in whichever
direction requires the smallest growth first followed by the other
direction if that fails.
Subtractive bridges will first attempt to satisfy requests for child
resources from I/O windows (including attempts to grow the windows). If
that fails, the request is passed up to the parent PCI bus directly
however.
The PCI-PCI bridge driver will try to use firmware-assigned ranges for
child BARs first and only allocate a "fresh" range if that specific range
cannot be accommodated in the I/O window. This allows systems where the
firmware assigns resources during boot but later wipes the I/O windows
(some ACPI BIOSen are known to do this) to "rediscover" the original I/O
window ranges.
The ACPI Host-PCI bridge driver has been adjusted to correctly honor
hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge
makes a wildcard request for an I/O window range.
The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option
is enabled. This is a transition aide to allow platforms that do not
yet support bus_activate_resource() and bus_adjust_resource() in their
Host-PCI bridge drivers (and possibly other drivers as needed) to use the
old driver for now. Once all platforms support the new driver, the
kernel option and old driver will be removed.
PR: kern/143874 kern/149306
Tested by: mav
Rationale:
- unlike current behavior this seems to be compliant with OSS
specification:
http://manuals.opensound.com/developer/SNDCTL_DSP_GETIPTR.html
- this seems to meet expectations of some OSS programs compiled for or
ported from Linux, e.g. ALSA OSS plugin
- this doesn't seem to break any programs as far as current testing
shows
Tested by: nox, hselasky
MFC after: 4 days
sectors with all-zeroes.
The zeroes come from a static buffer; null(4) uses a dynamic buffer for
the same purpose (for /dev/zero). It might be a good idea to have a
static, shared, read-only all-zeroes page somewhere in the kernel that
md(4), null(4) and any other code that needs zeroes could use.
Reviewed by: kib
MFC after: 3 weeks
constraints on the rman and reject attempts to manage a region that is out
of range.
- Fix various places that set rm_end incorrectly (to ~0 or ~0u instead of
~0ul).
- To preserve existing behavior, change rman_init() to set rm_start and
rm_end to allow managing the full range (0 to ~0ul) if they are not set by
the caller when rman_init() is called.
For these devices, the number of supported ports is read from a register
in BAR 0.
PR: kern/134878
Submitted by: David Wood david of wood2 org uk
MFC after: 1 week
The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.
The specifics:
* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
This is needed due to the different location the RTC registers live
with this chip; hopefully this will be undone in the future.
This does currently mean that enabling this option will break non-AR9130
builds, so don't enable it unless you're specifically building an image
for the AR913x SoC.
* Add the new probe, attach, EEPROM and PLL methods specific to Howl.
* Add a work-around to ah_eeprom_v14.c which disables some of the checks
for endian-ness and magic in the EEPROM image if an eepromdata block
is provided. This'll be fixed at a later stage by porting the ath9k
probe code and making sure it doesn't break in other setups (which
my previous attempt at this did.)
* Sprinkle Howl modifications throughput the interrupt path - it doesn't
implement the SYNC interrupt registers, so ignore those.
* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
were
* Sprinkle some other Howl workarounds in the reset path.
* Hard-code an alternative setup for the AR_CFG register for Howl, that
sets up things suitable for Big-Endian MIPS (which is the only platform
this chip is glued to.)
This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.
Caveats:
* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
chipset so I can't test it.
* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
it isn't implemented in ath9k. Please don't enable this.
* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.
allocated, not the maximum number of messages the device supports. The
spec only requires the former, and I believe I implemented the latter due
to misunderstanding an e-mail. In particular, this fixes an issue where
having several devices that all support 16 messages can run out of
IDT vectors on x86 even though the driver only uses a single message.
Submitted by: Bret Ketchum bcketchum of gmail
MFC after: 1 week
adding appropriate #ifdefs. For module builds the framework needs
adjustments for at least carp.
Reviewed by: gnn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 4 days
the watchdog, via the watchdog(9) interface.
For that, the WD_LASTVAL bitwise operation is used. It is mutually
exclusive with any explicit timout passing to the watchdogs.
The last timeout can be returned via the wdog_kern_last_timeout()
KPI.
- Add the possibility to pat the watchdogs installed via the watchdog(9)
interface from the kernel.
In order to do that the new KPI wdog_kern_pat() is offered and it does
accept normalized nanoseconds or WD_LASTVAL.
- Avoid to pass WD_ACTIVE down in the watchdog handlers. All the control
bit processing should over to the upper layer functions and not passed
down to the handlers at all.
These changes are intended to be used in order to fix up the watchdog
tripping in situation when the userland is busted, but protection is still
wanted (examples: shutdown syncing / disk dumping).
Sponsored by: Sandvine Incorporated
Reviewed by: emaste, des, cognet
MFC after: 2 weeks
will generate a short terminated USB transfer if
the maximum NCM frame size is greater than what
the driver can handle.
Reported by: Matthias Benesch
MFC after: 7 days
Approved by: thompsa (mentor)
- Also a couple minor tweaks to the TX code from the same source.
- Add the INET ioctl code which has been missing from this driver,
and which caused IP aliases to reset the interface.
- Last, some minor logic changes that just reflect upcoming
hardware support, but have no other functional effect now.
MFC after a week
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
spurious (and fatal) interrupt errors.
One user reported seeing this:
Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000
SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.
After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.
The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.
This patch does the following:
* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.
This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.
- Centralize PCI resource allocation/release.
- Enable flowid (TSS) support.
- Added "per-fastpath" locks and watchdog timeouts.
- Fixed problem where the CQ producer index was advanced beyond
the size of the CQ ring during initialization.
- Replaced hard-coded debug levels in some debug print statements.
- More style(9) fixes.
MFC after: Two weeks
should respond with all zeroes to any access to slave registers. Test with
PATA devices confirmed such behavior. Unluckily, Intel SATA controllers in
legacy emulation mode behave differently, not making any difference between
ATA and ATAPI devices. It causes false positive slave device detection and,
as result, command timeouts.
To workaround this problem, mask result of legacy-emulated soft-reset with
the device presence information received from the SATA-specific registers.
- TCO_MESSAGEx: TCO specific regs providing the ability to monitor BIOS
bootup activity.
- TCO_NEWCENTURY: reporting RTC year roll over.
- TCO_NMI2SMI_EN, TCO_NMI_NOW: controlling SMIs conversion to NMIs and
NMI trigger.
- SMI_GBL_EN: Enabling SMI delivery for all the northbridge controller.
MFC after: 10 days
This improves hard-reset and hot-plug on these ports.
- Device with ID 0x29218086 is a 2-port variant of ICH9 in legacy mode.
Skip probing for nonexistent slave devices there.
It allows to avoid false positive device detection under Xen, that caused
long probe delays due to subsequent IDENTIFY command timeouts.
MFC after: 1 month
that could have allowed the hardware pidx to reach the cidx even though
the freelist isn't empty. (Haven't actually seen this but it was there
waiting to happen..)
MFC after: 1 week
now a suitable base for all kinds of egress queues.
- Add control queues (sge_ctrlq) and allocate one of these per hardware
channel. They can be used to program filters and steer traffic (and
more).
MFC after: 1 week
- If a ENH_SENS TLV section exit the firmware is capable of doing
enhanced sensitivity calibration.
- Newer devices/firmwares have more calibration commands therefore
hardcoding the noise gain/reset commands no longer works. It is
supposed to use the next index after the newest calibration type
support. Read the command index of the TLV section if available.
This support has not worked for several years, and is not likely to work
again, unless Intel decides to release a native FreeBSD version of their
compiler. ;)
It's also marked inactive by the initvals, and enabled after
the baseband/PLL has been configured, but before the RF
registers have been programmed.
The origin and reason for this particular change is currently unknown.
Obtained from: Linux ath9k
- 6000 series devices need enhanced sensitivity calibration.
- 6000 series devices need a different setting for the shadow reg.
- set the IWN_FLAG_HAS_11N bit if the EEPROM says the device has 11n
support.
Obtained from: OpenBSD
Antenna diversity on the >= AR5416 is implemented differently than the
AR5212 and previous chips. So for now, and not to confuse things, just
disable it for now.
- read RSSI only for the active chains
- cast RSSI/NF to int8_t before passing it up to radiotap
- remove the htole64() for the timestamp
Obtained from: OpenBSD
- there is a local variable for sc->fw_dma, use that instead
- OpenBSD uses 5*hz to wait for firmware to be loaded
- in case the firmware module contains invalid data, actually release it
- use ATA_SE_EXCHANGED (SError.DIAG.X) bit to detect hot-plug events when
power-management enabled and ATA_SE_PHY_CHANGED (SError.DIAG.N) can't be
trusted;
- on controllers supporting staggered spin-up (SS) put unused channels
into Listen state instead of Off. It should still save some power, but
allow plug-in events to be detected;
- on controllers supporting cold presence detection (CPD), when power
management enabled, use CPD events to detect hot-plug in addition to PHY
events.
down. The ingress queue lock was unused and has been removed as part of
these changes.
- An in-flight egress update from the SGE must be handled before the
queue that requested it is destroyed. Wait for the update to arrive.
- Interrupt handlers must stop processing rx events for a queue before
the queue is destroyed. Events that have not yet been processed
should be ignored once the queue disappears.
MFC after: 1 week
from scratch. Remove htole16() calls, rxon.chan is an uint8_t,
ieee80211_chan2ieee() does return an ic_ieee as an int, but I heavily
doubt a htole16() will buy us anything here.
- IWN_TXOP_TO_US is equal to IEEE80211_TXOP_TO_US
- use IEEE80211_DUR_TU
- ieee80211_add_rates/ieee80211_add_xrates are public, use em
- copied ieee80211_add_ssid it is not public
Instead of spinning in a tight loop for up to 15 seconds, polling for device
readiness while it spins up, return reset completion just after PHY reports
"connect well" or 100ms connection timeout. If device was found, use callout
for checking device readiness with 100ms period up to full 31 second timeout.
This fixes system freeze for 5-10 seconds on drives hot plug-in.
- make SATA SIMs announce capabilities to handle SDB with Notification bit;
- make PMP driver honor this SIMs capability;
- make SATA XPT to negotiate and enable this feature for ATAPI devices.
This feature allows supporting SATA ATAPI devices to inform system about
some events happened, that may require attention. In my case this allows
LG GH22LS50 SATA DVR-RW drive to report tray open/close events. Events
reported to CAM in form of AC_SCSI_AEN async. Further they could be used
as a hints for checking device status and reporting media change to upper
layers, for example, via spoiling mechanism of GEOM.
diversity.
This is bit dirty and likely should be revised at a later date,
with an eye to unifying/tidying up the whole diversity setup
and allowing developers to do "tricky stuff" as they desire.
For now, this works.
* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.
* add a diversity flag to the HAL debugging section
* add a check to make sure the kite diversity code doesn't run
on boards that don't require it, as not all Kite chips will
implement it.
* add some debug statements when the diversity code makes
changes to the antenna diversity/combining setup.
controller port readiness (that should set just after PHY ready signal),
reduce wait time from 10s to 1s before trying more aggressive reset method.
This should improve system responsibility in some failure conditions.
Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.
The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
Instead of spinning in a tight loop for up to 15 seconds, polling for device
readiness while it spins up, return reset completion just after PHY reports
"connect well" or 100ms connection timeout. If device was found, use callout
for checking device readiness with 100ms period up to full 31 second timeout.
This fixes system freeze for 5-10 seconds on drives hot plug-in.
bus driver at detach, hence ehci_detach() does exactly this since r199718.
Submitted by: Luiz Otavio O Souza
MFC after: 7 days
Approved by: thompsa (mentor)
SCSI status errors to CAM (that was wrong, as it too often turned retriable
wire errors into non-retriable REQUEST SENSE errors), do it only for STALL
errors on control pipe of the CBI devices. STALL on control pipe is just
a one of the ways to report error for CBI devices.
PR: usb/150401, usb/154593.
Reviewed by: hselasky
MFC after: 1 week
ctl/ext noise floor values.
This routine doesn't check to see whether the radio is MIMO
capable - instead, it simply returns either the raw values,
the "nominal" values if the raw values aren't yet available
or are invalid, or '0' values if there's no valid channel/
no valid MIMO values.
Callers are expected to verify the radio is a MIMO radio
(which for now means it's an 11n chipset, there are non-11n
MIMO chipsets out there but I don't think we support them,
at least in MIMO mode) before exporting the MIMO values.
upper-level HAL.
Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.
This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.
safer for i386 because it can be easily over 4 GHz now. More worse, it can
be easily changed by user with 'machdep.tsc_freq' tunable (directly) or
cpufreq(4) (indirectly). Note it is intentionally not used in performance
critical paths to avoid performance regression (but we should, in theory).
Alternatively, we may add "virtual TSC" with lower frequency if maximum
frequency overflows 32 bits (and ignore possible incoherency as we do now).
chain to be corrupted.
- Removed many console print warnings and replaced with driver maintained
counters.
- Several style(9) fixes.
MFC after: One week.
improves command timeout handling.
Many thanks to Areca for continuing to support FreeBSD.
Submitted by: Ching-Lung Huang <ching2048 areca com tw>
MFC after: 2 months
This fixes a long standing bug in mxge(4) where "ifconfig mxge0 $IP"
did not bring the interface into a RUNNING state, like it does on
most (all?) other FreeBSD NIC drivers.
Thanks to gnn for mentioning the bug, and yongari for pointing out that
ether_ioctl() invokes ifp->if_init() in SIOCSIFADDR.
MFC after: 7 days
- Add the change made in em to the actual unrefreshed number
of descriptors is used as a basis in rxeof on the way out
to determine if more refresh is needed. NOTE: there is a
difference in the ring setup in igb, this is not accidental,
it is necessitated by hardware behavior, when you reset the
newer adapters it will not let you write RDH, it ALWAYS sets
it to 0. Thus the way em does it is not possible.
- Change the sysctl handling of flow control, it will now make
the change dynamically when the variable setting changes rather
than requiring a reset.
- Change the eee sysctl naming, validation found the old unintuitive :)
- Last but not least, some important performance tweaks in the TX
path, I found that UDP behavior could be drastically hindered or
improved with just small changes in the start loop. What I have
here is what testing has shown to be the best overall. Its interesting
to note that changing the clean threshold to start at a full half of
the ring, made a BIG difference in performance. I hope that this
will prove to be advantageous for most workloads.
MFC in a week.
show that there are perfectly working PM timers with occasional "hiccups",
probably because of an SMI. Now we ignore the maximum if it happens once in
the test loop and the width is small enough. Also, relax normal width a bit
to count in a boundary case.
Unlike other controllers which have more advanced jumbo support,
these controllers have one send ring, one standard receive producer
ring and one receive return ring. In order to receive jumbo frames
on the controllers, driver now will increase Rx buffer size to 9k.
Two Rx modes are supported on these controllers and I chose
standard Rx BDs over extended Rx BDs. The extended Rx BD mode
allows up to 4 segmentations for each Rx BDs such that kernel does
not have to allocate large buffer of contiguous memory for
receiving. The extended Rx BD mode is already used on controllers
that have separate jumbo receive ring. However, using extended Rx
BDs on BCM5714/BCM5715/BCM5780 reduces the number of Rx BDs to 256
entries which in turn may reduce the performance. Also UMA backed
page allocator for jumbo frame returns contiguous memory so using
extended Rx BD has no advantage on FreeBSD unless highly customized
local allocator implemented in driver is used.
To use jumbo buffers in standard receive ring, Rx buffer allocation
handler was changed to allocate MJUM9BYTES sized mbuf.
PR: kern/155192
Tested by: Vijay Singh <vijju.singh <> gmail dot com>
Submitted by: mjacob (initial version)
on the fact that real hardware has almost fixed cost to read the ACPI timer.
It is virtually always false for hardware emulation and it makes no sense to
read it multiple times, which is already quite expensive for full emulation.
