Genericise the (out of date) instructions from moving from stable to
current.

MFC after:	3 days


git-svn-id: svn://svn.freebsd.org/base/head@242396 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Correct attribution.


git-svn-id: svn://svn.freebsd.org/base/head@242398 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Pad and align the callout_cpu mtx to its own cacheline to reduce false
sharing especially on the default CPU 0 callout_cpu structure.

This will be followed up by attilio@ with a conversion to the new struct
mtx_padalign but doing this manual conversion first gives an easy MFC
candidate since mtx_padalign is a more extensive system change.

Sponsored by:	Intel
Reviewed by:	jeff, attilio
MFC after:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@242401 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Rework the known mutexes to benefit about staying on their own
cache line in order to avoid manual frobbing but using
struct mtx_padalign.

The sole exception being nvme and sxfge drivers, where the author
redefined CACHE_LINE_SIZE manually, so they need to be analyzed and
dealt with separately.

Reviwed by:	jimharris, alc


git-svn-id: svn://svn.freebsd.org/base/head@242402 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Correct code that was lost somewhere in the past,
this was designed to keep duplicate null vlan tags from
being added. When doing vlans purely via the switch
this problem will occur. Reported by external customer.


git-svn-id: svn://svn.freebsd.org/base/head@242403 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add the emulation PCI device id - these days, 0xabcd shows up all over
the internet as "AR9380 and later which didn't get its PCI ID written
in at power-on", so it's hardly an unknown constant.

Obtained from:	Qualcomm Atheros


git-svn-id: svn://svn.freebsd.org/base/head@242406 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Add in the last random assortment of missing bits for the AR9380 HAL.

Obtained from:	Qualcomm Atheros


git-svn-id: svn://svn.freebsd.org/base/head@242407 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
HAL updates!

* Add some more ANI spur immunity levels.
* For AR5111 radios attached to an AR5212, limit the 5GHz channels
  that are available. A later revision of the AR5111 supports the 4.9GHz
  PSB channels but right now there's no check in place for the radio
  revision.

  If someone wants PSB support on AR5212+AR5111 radios then please let
  me know and I'll add the relevant version check.

Obtained from:	Qualcomm Atheros


git-svn-id: svn://svn.freebsd.org/base/head@242408 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Oops - missing from the last commit - add ANI immunity levels for AR9160.

Obtained from:	Qualcomm Atheros


git-svn-id: svn://svn.freebsd.org/base/head@242409 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Oops - this was incorrectly removed in a previous commit.


git-svn-id: svn://svn.freebsd.org/base/head@242411 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Since the PLL changes aren't in here yet for the AR9130 half/quarter
rate support, disable it.


git-svn-id: svn://svn.freebsd.org/base/head@242412 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
ASUS EeePC 1001px has strange variant of ALC269 CODEC, that mutes speaker
if unused in that configuration mixer at NID 15 is muted.  Probably CODEC
incorrectly reports its internal connections.  Hide that muter from the
driver to avoid muting and make built-in speaker work.

There are several different CODECs sharing this ID and I have not enough
information about them and the bug to implement more universal solution.

Tested by:	Big Yuuta <init.py@gmail.com>
MFC after:	2 weeks


git-svn-id: svn://svn.freebsd.org/base/head@242417 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Use callout_reset_curcpu to allow the callout to be handled by the
current CPU and not always CPU 0.

This has the added benefit of reducing a huge amount of spinlock
contention on the callout_cpu spinlock for CPU 0.

Sponsored by:	Intel


git-svn-id: svn://svn.freebsd.org/base/head@242420 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
A few important fixes:
  - Testing TSO6 has led me to discover that HW RSC is
    a problematic feature, it is ONLY designed to work
    with IPv4 in the first place, and if IP forwarding
    is done it can't be disabled as LRO in the stack,
    also initial testing we've done at Intel shows an
    equal performance using TSO[46] on the TX and LRO
    on RX, if you ran older code on 82599 or later hardware
    you actually could have detrimental performance for
    this reason. So I am disabling the feature by default
    and all our adapters will now use LRO instead.

  - If you have flow control off and multiple queues it
    was possible when the buffer of one queue becomes
    full that all RX movement is stalled, to eliminate
    this problem a feature bit is now set that will allow
    packets to be dropped when full rather than stall.
    Note, the default is to have flow control on, and this
    keeps this from happening.

  - Because of the recent fixes in the stack, LRO is now
    auto-disabled when problematic, so I have decided to
    enable it by default in the capabilities in the driver.

  - There are some 1G modules used by some customers, a couple
    small tweaks to properly support those in the media code.

  - A note: we have now done some testing of TSO6 and using
    LRO with IPv6 and it all works great!! Seeing line rate
    in both directions in best cases. Thanks bz for your
    excellent work!!


git-svn-id: svn://svn.freebsd.org/base/head@242421 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Only four specific ATA PIO commands transfer several sectors per DRQ block
(interrupt).  All other ATA PIO commands transfer one sector or 512 bytes
at one time.  Hardcode these exceptions in ata(4) with ATA_CAM option.
This fixes timeout of READ LOG EXT command used by `smartctl -x /dev/adaX`.


git-svn-id: svn://svn.freebsd.org/base/head@242422 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Handle the management port on the EBT5600 and disable loopback.  The XAUI
port connected to the Broadcom switch does not seem operable, but it's unclear
if that's simply due to a lack of configuration information for the switch.
The switch does not seem to present any identifying information via MDIO,
and is a BCM56512.


git-svn-id: svn://svn.freebsd.org/base/head@242423 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Small textdump enhancements.

Allow textdumps to be called explicitly from DDB.

If "dump" is called in DDB and textdumps are enabled then abort the
dump and tell the user to turn off textdumps.

Add options TEXTDUMP_PREFERRED to turn textdumps on by default.
Add options TEXTDUMP_VERBOSE to be a bit more verbose while textdumping.

Reviewed by: rwatson

MFC after:	2 weeks


git-svn-id: svn://svn.freebsd.org/base/head@242424 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Remove TCP/UDP checksum offloading feature for IP fragmented
datagrams.  Traditionally upper stack fragmented packets without
computing TCP/UDP checksum and these datagrams were passed to
driver.  But there are chances that other packets slip into the
interface queue in SMP world. If this happens firmware running on
MIPS 4000 processor in the controller would see mixed packets and
it shall send out corrupted packets.
While I'm here simplify checksum offloading setup.

MFC After:	1 week


git-svn-id: svn://svn.freebsd.org/base/head@242425 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
TCP/UDP checksum offloading feature for IP fragmented datagram was
removed in r99417.  bge(4) controllers can do TCP checksum offload
for IP fragmented datagrams but unlike ti(4), it lacks UDP checksum
offloading for IP fragmented datagrams. The problem was bge(4)
blindly requested TCP/UDP checksum for IP fragmented datagrams such
that it resulted in corrupted UDP datagrams before r99417.
Remove remaining code for TCP checksum offloading for IP fragmented
datagrams which should have been removed in r99417.


git-svn-id: svn://svn.freebsd.org/base/head@242426 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Minor mdoc fix.


git-svn-id: svn://svn.freebsd.org/base/head@242427 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f