Age | Commit message (Collapse) | Author |
|
ok mlarkin
|
|
the backout police even though it wasn't responsible for anything.
pointed out by tb@
|
|
Performance regression reported by deraadt@ and uvm_fault reported by fcambus@.
I will be poking further at this out of tree.
|
|
Since we now sync the entire Rx DMA buffer the SYNC_RESP_STRUCT() macro which
was used to sync just parts of the buffer can be replaced by assignments.
The SYNC_RESP_PTR() macro was already unused so just remove it.
The ADVANCE_RXQ() macro was used just once so expand it in place.
|
|
All callers were passing the same constant IWM_RBUF_SIZE, which is derived
from the smallest RX buffer the hardware supports (4k). Smaller sizes don't
make sense anyway and larger sizes are not on our horizon for now.
|
|
a frame which was retried N times was retried just once.
This punishes retry-heavy data rates even more and should reduce latency.
It does not seem to have a noticable effect on net throughput in my testing.
If this change causes throughput problems for anyone, let me know.
ok tb@ mlarkin@
|
|
this was wrong and was corrected at the end of last year in rev 1.140.
Before then a 64 bit BAR was not enforced as the test was wrong.
It turns out there exist 82598 parts which have a 32 bit BAR so change
the test to only require a memory BAR and not a 64 bit memory BAR.
Problem reported by Robert Blacquiere. ok mikeb@
|
|
The magic commands to capture raw 802.11 frames on e.g. channel 1 are:
ifconfig iwm0 mediaopt monitor chan 1
tcpdump -n -i iwm0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwm.pcap
ifconfig iwm0 -mediaopt monitor -chan
|
|
We can now clear SINGLE_FRAME_MSK in the receive configuration register.
Linux has not set this bit in years, and Dragonfly stopped setting it
in commit b5eb43f0280bbcfd26af51cf5a4b8e8ff3590b67.
This is a prerequisite for monitor mode since the firmware seems to ignore
the SINGLE_FRAME_MSK bit while running in monitor mode and sends us garbage.
Tested on 7260, 7265, and 8260 devices.
|
|
the size of the corresponding id field in struct iwm_host_cmd.
Patch by Imre Vadasz.
|
|
iwm_disable_rx_dma() was unintentionally releasing the nic lock too early.
Patch by Imre Vadasz.
|
|
The iwm_{read,write}_prph() calls don't grab the nic lock themselves
so make sure to acquire it where necessary.
The iwm_{set,clear}_bits_prph() on the other hand acquire/release the
nic lock themselves. Since the nic lock doesn't do recursive locking
we need to be careful to avoid accidentally releasing the nic lock
too early that way.
Patch by Imre Vadasz.
|
|
From Hiltjo Posthuma.
|
|
|
|
PCIE entry as it used the same product id.
Add another PLX/Avago/"Broadcom" PCIE bridge seen in the wild while here.
|
|
on amd64 and i386.
|
|
tested by bluhm@, ststp@ and Bryan Vyhmeister.
ok bluhm@ ststp@
|
|
from Brad
|
|
warnings. Makes non diagnostic kernel compile.
OK kettenis@
|
|
From Anton Lindqvist (anton.lindqvist(at)gmail.com)
|
|
OK jsg@
|
|
constants.
The consensus is that if both operands are constant, we don't need
mallocarray. Reminded by tedu@
ok deraadt@
|
|
The device tree that ships with the overdrive 1000 has an interrupt-map
property that is known to be wrong. Using MSI on msk makes the builtin
Ethernet on the overdrive 1000 work.
Tested on arm64 with
"Marvell Yukon 88E8059" rev 0x00, Yukon-2 Optima (0x1)
and i386 with
"Marvell Yukon 88E8072" rev 0x10, Yukon-2 Extreme rev. B0 (0x2)
Committing this early in the release cycle to try find cases where using
MSI doesn't work.
Based on part of an earlier patch from jmatthew@
ok jmatthew@ kettenis@
|
|
|
|
ok deraadt@
|
|
ok deraadt@
|
|
ok deraadt@
|
|
ok deraadt@
|
|
could be running inside a driver that will be force-detached, or due
to tsleep end up disrupting the softstate/hardstate contract. At
suspend time, quisce all these callbacks by waiting for completion.
This issue has never been observed for real, but may be implicated in
suspend/resume failures.
ok kettenis guenther mlarkin
|
|
consumes two ring entries per segment, halving the effective size of the
rings, but keeps things simple. This is required for the onboard nic
on the Overdrive 1000 to work.
ok kettenis@, tested on i386 by jsg@
|
|
Errors will result in nice clean panic messages so we know what's wrong.
Reviewed by dhill visa natano jsg.
|
|
|
|
From Anton Lindqvist (anton.lindqvist(at)gmail.com)
|
|
ok visa
|
|
|
|
extra zero'ing of variables not needed because softc is pre-zero'd.
ok jsg
|
|
ok dhill
|
|
|
|
|
|
need to be installed by hand until the iwm-firmware package has been updated.
This includes handling (by ignoring) of IWM_UCODE_TLV_FW_MEM_SEG and
IWM_DEBUG_LOG_MSG firmware commands. Mostly stolen from dragonflybsd.
With this in the X270 has working ethernet and wifi.
Commit! deraadt@
|
|
|
|
|
|
them, but for release let's be conservative and use 0.
|
|
the received packet fits in a single mbuf cluster, which isn't necessarily
the case. This might fix the pool corruption seen by jcs@.
ok jcs@, jmatthew@, deraadt@
|
|
Also, the firmware was rejecting RTS frames so iwi(4) didn't work against
an OpenBSD athn(4) hostap anymore; fix the config sent to firmware.
Prompted by report from bg2200 at jamesjerkinscomputer on misc@
ok deraadt@
|
|
that are now covered by the generic class matching.
|
|
0 "No class specific protocol required" in addition to the existing
protocol 1 "AT Commands: V.250 etc" match.
This lets umodem(4) attach to the serial console on the overdrive 1000
which is a usb type-b socket on the back of the box not a db9 like the
overdrive 3000.
|
|
a wrong rate being reported when a unsupported rate was requested.
|
|
Michael W. Bombardieri <mb at ii.net>. Thanks.
|
|
Thanks!
|