-It has new hardware support
-It uses a new method of TX cleanup called Head Write Back
-It includes the provisional generic TCP LRO feature contributed
by Myricom and made general purpose by me. This should move into
the stack upon approval but for this driver drop its in here.
-Also bug fixes and etc...
MFC in a week if no serious issues arise.
so the index needs to be translated into an offset. While we
did add the offset (0x10), we forgot to account for the width.
Tested by: Thomas Vogt
MFC after: 3 days
- Obsolete redundant inst_name and unit members of struct sym_hcb.
- Fix three more NULL vs. 0 confusions.
- Use device_set_softc(9) to tell the bus layer that this driver
allocates a instance of struct sym_hcb itself.
- Rename BGE_FLAG_EEPROM to BGE_FLAG_EADDR to underline it's absence means
"there's no chip containing an Ethernet address fitted to the BGE chip
so we have to get it from the firmware instead" rather than "there's no
EEPROM, but maybe NVRAM or something else".
- Don't treat BCM5906[M] generally like chips w/o BGE_FLAG_EADDR set, just
in the two cases really necessary. This gets us line with the original
patch for DragonFlyBSD.
- For sparc64 restore the intended behavior of obtaining the Ethernet
address from the firmware in case BGE_FLAG_EADDR is not set, even for
BCM5906[M].
- Fix some style(9) bugs introduced with rev. 1.208 of if_bge.c
Approved by: jhb
Additional testing by: Thomas Nystroem (BCM5906)
Add support for the Apple USB Ethernet adapter.
Work around the "latch in at the first working PHY address hack",
that fails for this adapter because it returns 0xffff when reading
from lower PHY addresses. Also add more debugging printfs
Obtained from: OpenBSD
MFC After: 3 days
o correct mapping of CCK rates to PLCP; was using nonstandard Ralink
values which just happened to also be used by Zydas (so went unnoticed)
o change ieee80211_plcp2rate api to take a phy type instead of a flag
that indicates ofdm/!ofdm
o update drivers to match (restore per-driver code to map rate->PLCP)
Reviewed by: sephe, weongyo, thompsa
o add IEEE80211_C_STA capability to indicate sta mode is supported
(was previously assumed) and mark drivers as capable
o add ieee80211_opcap array to map an opmode to the equivalent capability bit
o move IEEE80211_C_OPMODE definition to where capabilities are defined so it's
clear it should be kept in sync (on future additions)
o check device capabilities in clone create before trying to create a vap;
this makes driver checks unneeded
o make error codes return on failed clone request unique
o temporarily add console printfs on clone request failures to aid in
debugging; these will move under DIAGNOSTIC or similar before release
Instead use the worldwide known MAX() function.
This should fix problems with negative values showing up on
dev.cpu.%d.temperature.
This is slightly different from the fix in the PR.
Submitted by: KOIE Hidetaka <hide at koie.org>
PR: 123542
Handle cases where dma function pointers may be NULL, and where
the max_iosize can't be derived from a DMA data structure. For
the latter, revert to the prior behaviour of using DFLTPHYS for
the max i/o size when there is no other data.
Reviewed by: marcel
No objection by: sos
aligned on an 8 byte boundary. Prior to rev 1.36 this wasn't a problem
because mbuf clusters tend be naturally aligned. The switch to using
split buffers with the first buffer being the embedded data area of the
mbuf has broken this assumption, at least on i386, causing a complete
failure of RX functionality. Fix this for now by using a full cluster for
the first RX buffer. A more sophisticated approach could be done with the
old buffer scheme to realign the m_data pointer with m_adj(), but I'm also
not clear on performance benefits of this old scheme or the performance
implications of adding an m_adj() call to every allocation.
perform various operations on a controller. Specifically, for each mpt(4)
device, create a character device in devfs which accepts ioctl requests for
reading and writing configuration pages and performing RAID actions.
MFC after: 1 week
Reviewed by: scottl
all cards/modes.
In addition to the intr forcing added with rev. 1.205 adopt the other
places to use the same logic.
We need to exclude a few chips/revisions (5700, 5788) from using the
enhanced version and fall back to the old way as that is the only
method they support.
Tested by: phk
Suggested by: davidch, Broadcom (thanks a lot for the help!)
MFC after: 16 days
- add / remove clients from cxgb_main.c now
- change ifdef TOE_ENABLED to TCP_OFFLOAD_DISABLE
- update copyrights
- fix transmit data mismatch bug caused by not setting SB_NOCOALESCE
on tx sockbuf on passive connections
- fix receive sequence mismatch bug caused by not setting SB_NOCOALESCE
on rx sockbuf on passive connections
- don't sleep without checking SBS_CANTRCVMORE first
- various ddp ordering fixes
Supported by: Chelsio Inc.
ALT_BREAK_TO_DEBUGGER. In addition to "Enter ~ ctrl-B" (to enter the
debugger), there is now "Enter ~ ctrl-P" (force panic) and
"Enter ~ ctrl-R" (request clean reboot, ala ctrl-alt-del on syscons).
We've used variations of this at work. The force panic sequence is
best used with KDB_UNATTENDED for when you just want it to dump and
get on with it.
The reboot request is a safer way of getting into single user than
a power cycle. eg: you've hosed the ability to log in (pam, rtld, etc).
It gives init the reboot signal, which causes an orderly reboot.
I've taken my best guess at what the !x86 and non-sio code changes
should be.
This also makes sio release its spinlock before calling KDB/DDB.
- Limit grabbing the lock to SIOCSIFFLAGS.
- Move ieee80211_start_all() to SIOCSIFFLAGS.
- Remove SIOCSIFMEDIA as it is not useful.
- Limit ether_ioctl to only SIOCGIFADDR. SIOCSIFADDR and SIOCSIFMTU have no
affect as there is no input/output path in the vap parent. The vap code
will handle the reinit of the mac address changes.
- Split off ndis_ioctl_80211 as it was getting too different to wired devices.
This fixes a copyout while locked and a lock recursion.
Reviewed by: sam
10/100 operation and place the mailbox registers at a different offset.
They also do not have an EEPROM, so the MAC address must be read from
NVRAM instead.
MFC after: 1 month
PR: kern/118975
Submitted by: benjsc, Thomas Nyström thn at saeab dot se
Submitted by: sephe (original patch for DragonflyBSD)
