driver is running driver would have already completed flow control
configuration. This change removes unnecessary media changes in
controller reconfiguration cases such that it does not trigger link
reestablishment for configuration change requests like promiscuous
mode change.
Reported by: Many
Tested by: Mike Tancsa <mike <> sentex dot net>
MFC after: 1 week
* printf -> device_printf
* print the buffer pointer and sequence number for any buffer that wasn't
correctly tidied up before it was freed. This is to aid in some
current SMP TX debugging stalls.
PR: kern/166190
For example, some BIOS for AMD SB600 south bridge may map HPET MMIO base
address as a memory BAR for SMBus controller depending on a PM register
configuration. Before r231161 (and r232086, subsequent MFC to stable/9),
it was not fatal but hpet(4) just failed to attach. Since we probe and
attach HPET earlier than PCI devices now, it caused unfortunate hard lockup.
With this patch, it does not hang any more and HPET works at the same time.
Clean up some style nits while I am in the neighborhood.
PR: kern/165647
Reviewed by: jhb
MFC after: 3 days
remaining drivers that haven't been converted have various problems or
complexities that will be dealt with later. This list includes:
hptrr, hptmv, hpt27xx - device aggregation across multiple parents
drm - want to talk to the maintainer first
tsec, sec - Openfirmware devices, not sure if changes are warranted
fatm - Done except for unused testing code
usb - want to talk to the maintainer first
ce, cp, ctau, cx - Significant driver changes needed to convey parent info
There are also devices tucked into architecture subtrees that I'll leave
for the respective maintainers to deal with.
updated.
o Number of times NIC ran out of RX buffer descriptors
o Number of inbound packet errors
o Number of inbound packets that were chosen to be discarded
Previously only the discarded packet counter was used to update
if_ierrors. This change fixes wrong if_ierrors counter on
BCM570[0-4] controllers. For BCM5705 and later controllers bge(4)
already correctly counted it.
Reported by: Eugene Grosbein <egrosbein <> rdtc dot ru>
device in device attach. This would help to narrow down issue to a
specific controller and operating mode of the controller.
While I'm here rename BGE_MISCCFG_BOARD_ID with
BGE_MISCCFG_BOARD_ID_MASK.
AMD-8131 PCI-X bridge. The bridge seems to reorder write access to
mailbox registers such that it caused watchdog timeouts by
out-of-order TX completions.
Tested by: Michael L. Squires <mikes <> siralan dot org >
Reviewed by: jhb
Lower (ISA) IRQs are working, but allowed mask is not set correctly.
Block both by default to allow HP BL465c G6 blade system to boot.
Reported by: Attila Nagy <bra@fsn.hu>
MFC after: 1 week
Although access to the flags to check/set OACTIVE is racy due to how
the default if_start() function works, this should remove any races
with read/modify/write between threads.
don't setup the avp mcast queue.
This is a bit annoying though - it turns out the mcast queue isn't
initialised for STA mode but it's then touched to see whether anything
is in it. That should be fixed in a subsequent commit.
Noticed by: gperez@entel.upc.edu
PR: kern/165895
After 8.0-RELEASE, iwi(4) doesn't send any data frames in infrastructure
mode.
Bacause of the condition `while (frm < efrm)', IEEE80211_VERIFY_LENGTH()
was checking item length beyond the ieee80211_frame region, and returned
from iwi_checkforqos() without setting flags, capinfo and associd.
In infrastructure mode associd is required, so this problem causes
discarding mbuf in ieee80211_start().
PR: kern/165819
Tested/Reviewed/Supported by: bschmidt and adrian
MFC after: 1 week
In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse)
I saw the following occur:
* the air was considered "busy" a lot of the time;
* the cabq time is quite short due to staggered beacons being enabled;
* it just wasn't able to keep up TX'ing CABQ frames;
* .. and the cabq would swallow up all the TX ath_buf's.
This patch introduces a twiddle which allows the maximum cabq depth to be
set, forcing further frames to be dropped.
It defaults to the TX buffer count at the moment, so the default behaviour
isn't changed.
I've also started fleshing out a similar setup for the data path, so
it doesn't swallow up all the available TX buffers and preventing management
frames (such as ADDBA) out.
PR: kern/165895
frames with stations in power saving mode.
I'm not (yet) sure how to handle TX'ing aggregates frames to stations
that are in power saving mode, or whether that's even a feasible thing
to do. So in order to (mostly) not forget, leave a couple of comments
in the code.
The code presently assumes that the aggregation TID state for an ath_node
is locked not by the ath_node lock or a node+TID lock, but behind the
hardware queue said TID maps to. This assumption is going to be
incorrect for stations in power saving mode as we'll be TX'ing frames
on the multicast queue.
In any case, I'm afraid its a "later problem". :/
This function must be called with both the source and destination TXQs
locked or things will get hairy.
I added this as part of some debugging in a PR but it turned out to not
be the cause. I still think it's -correct- so, here it is.
the last buffer in the list.
The current behaviour (due to me, so pointy hat is firmly on my head here)
was incorrect - it was setting the link pointer to the last descriptor
of the _first_ buffer in the TXQ. Instead, it should have set it to the
last descriptor in the _last_ buffer in the TXQ.
This showed up as occasional TX stalls with frames in the TXQ but no
TX progress being made. Further inspection showed the TXQ looked like
it contained multiple "lists" of frames - there'd be a list of correct
frames, then a NULL link pointer, but there'd be a next buffer in the
list.
Since this code is only called upon an interface reset, it's likely
this only began showing up when I started doing stress testing
in environments which annoy the radios enough to cause lockups.
I've not yet any TX stalls with this patch applied.
PR: kern/165866
Expand pci_save_state and pci_restore_state to save more of
the config state for PCI Express and PCI-X devices. Various
writable control registers are present in PCI Express that
can potentially be lost over suspend/resume cycle.
This change is modeled after similar functionality in Linux.
Reviewed by: wlosh,jhb
MFC after: 1 month
all for platforms that only have 32-bit bus addresses. Second, remove
the 'tag_valid' flag from the softc. Instead, if we don't create a
tag in pci_attach_common(), just cache the value of our parent's tag
so that we always have a valid tag to return.
Winbond Super I/O chips.
With minor efforts it should be possible the extend the driver to support
further chips/revisions available from Winbond. In the simplest case
only new IDs need to be added, while different chipsets might require
their own function to enter extended function mode, etc.
Sponsored by: Sandvine Incorporated ULC (in 2011)
Reviewed by: emaste, brueffer
MFC after: 2 weeks
This lets specify whereabouts of the parent PHY for a given MAC node
(and get rid of ugly kludges in mge(4) and tsec(4)).
Obtained from: Semihalf
MFC after: 1 week
- pci_find_extcap() is repurposed to be used for fetching PCI-express
extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>).
- pci_find_htcap() can be used to locate a specific HyperTransport
capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>).
- Cache the starting location of the PCI-express capability for PCI-express
devices in PCI device ivars.
