When we open the disk, check the type of partition table, that has
been detected. If this is BSD label, then we assume this is DD mode.
Reported by: dim@
in SUPER-speed mode, USB 3.0.
This feature has not been tested yet, due to lack of hardware.
This feature is useful when implementing protocols like UASP,
USB attached SCSI which promises higher USB mass storage throughput.
This patch also implements support for hardware processing of endpoints
for increased performance. The switching to hardware processing
of an endpoint is done via a callback to the USB controller driver. The
stream feature is implemented like a variant of a hardware USB protocol.
USB controller drivers implementing device mode needs to be updated to
implement the new "xfer_stall" USB controller method and remove the
"xfer" argument from the "set_stall" method.
The API's toward existing USB drivers are preserved. To setup a USB transfer
in stream mode, set the "stream_id" field of the USB config structure to
the desired value.
The maximum number of BULK streams is currently hardcoded and limited to 8
via a define in usb_freebsd.h.
All USB drivers should be re-compiled after this change.
LibUSB will be updated next week to support streams mode. A new IOCTL to
setup BULK streams as already been implemented. The ugen device nodes
currently only supports stream ID zero.
The FreeBSD version has been bumped.
MFC after: 2 weeks
of this hardware still running (close to twenty years now).
2. Quiesece and use ENC_VLOG instead of ENC_LOG for most
complaints. That is, they're visible with bootverbose, but
otherwise quiesced and not repeatedly spamming messages
with constant reminders that hardware in this space is
rarely fully compliant.
MFC after: 1 month
necessary to "do" EDMA.
It was just using the TX completion status for logging information about
the descriptor completion. Since with EDMA we don't know this without
checking the TX completion FIFO, we can't provide this information.
So don't.
Now that I understand what's going on with this, I've realised that
it's going to be quite difficult to implement a processq method in
the EDMA case. Because there's a separate TX status FIFO, I can't
just run processq() on each EDMA TXQ to see what's finished.
i have to actually run the TX status queue and handle individual
TXQs.
So:
* unmethodize ath_tx_processq();
* leave ath_tx_draintxq() as a method, as it only uses the completion status
for debugging rather than actively completing the frames (ie, all frames
here are failed);
* Methodize ath_draintxq().
The EDMA ath_draintxq() will have to take care of running the TX
completion FIFO before (potentially) freeing frames in the queue.
The only two places where ath_tx_draintxq() (on a single TXQ) are used:
* ath_draintxq(); and
* the CABQ handling in the beacon setup code - it drains the CABQ before
populating the CABQ with frames for a new beacon (when doing multi-VAP
operation.)
So it's quite possible that once I methodize the CABQ and beacon handling,
I can just drop ath_tx_draintxq() in its entirety.
Finally, it's also quite possible that I can remove ath_tx_draintxq()
in the future and just "teach" it to not check the status when doing
EDMA.
EDMA HAL hardware.
* The EDMA HAL code assumes the nexttbtt and intval values are in TU/8
units, rather than TU. For now, just "hack" around that here, at least
until I code up something to translate it in the HAL.
* Setup some different TXQ flags for EDMA hardware.
* The EDMA HAL doesn't support setting the first rate series via
ath_hal_setuptxdesc() - instead, a call to ath_hal_set11nratescenario()
is always required. So for now, just do an 11n rate series setup
for EDMA beacon frames.
This allows my AR9380 to successfully transmit beacon frames.
However, CABQ TX and all normal data frame TX and TX completion is
still not functional and will require some more significant code churn
to make work.
I was having TX hang issues, which I root caused to having the
legacy ath_hal_setupxtxdesc() called, rather than the 11n rate scenario
setup code. This meant that rate control information wasn't being
put into frames, causing the MAC to stall/hang.
* Add ATH_TXQ_FIRST() for easy tasting of what's on the list;
* Add an "axq_fifo_depth" for easy tracking of how deep the current
FIFO is;
* Flesh out the handoff (mcast, hw) functions;
* Begin fleshing out a TX ISR proc, which tastes the TX status FIFO.
The legacy hardware stuffs the TX completion at the end of the final frame
descriptor (or final sub-frame when doing aggregate.) So it's feasible
to do a per-TXQ drain and process, as the needed info is right there.
For EDMA hardware, there's a separate TX completion FIFO. So the TX
process routine needs to read the single FIFO and then process the
frames in each hardware queue.
This makes it difficult to do a per-queue process, as you'll end up with
frames in the TX completion FIFO for a different TXQ to the one you've
passed to ath_tx_draintxq() or ath_tx_processq().
Testing:
I've tested the TX queue and TX completion code in hostap mode on an
AR9380. Beacon frames successfully transmit and the completion routine
is called. Occasional data frames end up in TXQ 1 and are also
successfully completed.
However, this requires some changes to the beacon code path as:
* The AR9380 beacon configuration API is now in TU/8, rather than
TU;
* The AR9380 TX API requires the rate control is setup using a call
to setup11nratescenario, rather than having the try0 series setup
(rate/tries for the first series); so the beacon won't go out.
I'll follow this up with commits to the beacon code.
8 or more cores to improve utilization. None of my tests on 2xXeon (2x6x2)
system shown any slowdown from mentioned "excess thrashing". Same time in
pbzip2 test with number of threads more then number of CPUs I see up to 10%
speedup with SMT disabled and up 5% with SMT enabled. Thinking about
trashing I was trying to limit that stealing within same last level cache,
but got only worse results. Present code any way prefers to steal threads
from topologically closer cores.
Sponsored by: iXsystems, Inc.
On Windows, AUX is the auxiliary device, usually pointing to COM1.
Therefore it is forbidden to create a file named aux.c. To make it a bit
easier for Windows users to check out our source code, rename this file
to auxv.c.
MFC after: 1 month
Discussed with: kib
Suggested by: Eric van Gyzen <eric vangyzen net>
they need to refer to static constants, which C99 does not allow for
extern inline functions.
While here, change a comment in e_rem_pio2f.c to mention the correct
number of bits.
Reviewed by: bde
MFC after: 1 week
ARM EABI the syscall value will be moved to a register to ease adding thumb
support. When this happens decoding of the instruction will no longer be
required.
- remove extra dynamic variable initializations;
- restore (4BSD) and implement (ULE) hogticks variable setting;
- make sched_rr_interval() more tolerant to options;
- restore (4BSD) and implement (ULE) kern.sched.quantum sysctl, a more
user-friendly wrapper for sched_slice;
- tune some sysctl descriptions;
- make some style fixes.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
the device_detach() function doesn't block on UCOM device
drivers until the TTY handle is closed by the userspace
application. This is implemented by a postpone of the
softc free where the UCOM structures reside until the
TTY references are gone.
Discussed with: kib, ed
MFC after: 2 weeks
Extend the callback table of UCOM to include a
"ucom_free" function pointer which is called when
all refs on a UCOM super structure is gone.
Implement various helper functions to handle
refcounting and draining on the UCOM super
structure.
Implement macro which can be used in device
drivers to avoid module unload before all
pending TTY references are gone.
The UCOM API is backwards compatible after this
change and device drivers require no changes
to function with this change. Only a recompilation
of UCOM device drivers is required. The FreeBSD
version has been bumped in that regard.
Discussed with: kib, ed
MFC after: 2 weeks
allocated softc structure which is returned by
device_get_softc(). This method can be used to
easily implement softc refcounting. This can be
desirable when the softc has memory references
which are controlled by userspace handles for
example.
This solves the problem of blocking the caller
of device_detach() for a non-deterministic time.
Discussed with: kib, ed
MFC after: 2 weeks
from pmap_pte(). PT_SET_MA() is not a queued mapping update, but instead
an immediate mapping update, so the page queues lock is not required here.
Reviewed by: cperciva
The machine-independent parts of the virtual memory system always pass a
valid pmap to the pmap functions that require one. Remove the checks for
NULL. (These checks have their origins in the Mach pmap.c that was
integrated into BSD. None of the new code written specifically for
FreeBSD included them.)
folding to 64 bits, while SHA1 code is big endian. Therefore, a bswap32
is required before using the value.
Without this change, the implementation does not conform to test vector
found in RFC 2289.
PR: bin/170519
Submitted by: Arthur Mesh <arthurmesh gmail com> (with changes)
MFC after: 1 week
