On Wed, Oct 11, 2023 at 02:05:52PM +0200, Stefan Sperling wrote:
> Anyway, here is an eephy(4) diff to enable/disable delays on the 88E1512.
That diff wasn't quite right. The register offset should be 0x21,
and Linux configures delays every time after link auto-negotiation.
I am still uns
On Wed, Oct 11, 2023 at 10:27:24AM +0200, Stefan Sperling wrote:
> On Tue, Oct 10, 2023 at 09:06:59PM +0200, Mark Kettenis wrote:
> > > OK for your diff. Please put it in and I'll rebase on top.
> >
> > done
>
> Thanks. Here is a rebased version. Re-tested with
i.c dwqe_pci
+
# Neterion Xframe 10 Gigabit ethernet
device xge: ether, ifnet, ifmedia
attach xge at pci
blob - /dev/null
blob + d157f116c025d882f1ec8df84b4c3deca3ca340f (mode 644)
--- /dev/null
+++ sys/dev/pci/if_dwqe_pci.c
@@ -0,0 +1,154 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2
On Tue, Oct 10, 2023 at 11:41:39PM +0200, Mark Kettenis wrote:
> The firmware for the BCM4388 has yet another version of the "escan"
> command. But we can treat it the same as v2 since it just added a new
> parameter in place of some padding. We just set that new parameter to
> zero, which
On Tue, Oct 10, 2023 at 08:41:37PM +0200, Mark Kettenis wrote:
> So the GMAC_VERSION #define is simply wrong. We should commit the
> diff attached and drop the sc_core stuff you added below.
That means all our supported chips are GMAC4 and later? Good to know.
> > + switch
# Intel Elkhart Lake Ethernet
+attach dwqe at pci with dwqe_pci
+file dev/pci/if_dwqe_pci.c dwqe_pci
+
# Neterion Xframe 10 Gigabit ethernet
device xge: ether, ifnet, ifmedia
attach xge at pci
blob - /dev/null
blob + 101b5670451611858f70b95a1082442b47056600 (mode 644)
--- /dev
On Sun, Sep 24, 2023 at 07:06:35AM +0200, Walter Alejandro Iglesias wrote:
> Hi Ingo,
>
> On Thu, Sep 21, 2023 at 03:04:24PM +0200, Ingo Schwarze wrote:
> > In general, the tool for checking the validity of UTF-8 strings
> > is a simple loop around mblen(3) if you want to report the precise
> >
On Thu, Sep 21, 2023 at 01:25:01PM +0200, Walter Alejandro Iglesias wrote:
> I corrected many of the things you pointed me, but not all. The
> function I use to check utf8 is mine, I use it in a pair of little
> programs which I've *hardly* checked for memory leacks. I know my
> function looks
On Sat, Sep 02, 2023 at 12:59:51PM +0200, Peter Hessler wrote:
> I just upgraded to -current and didn't have this patch in for a little
> bit, and woof that was super noticable. Still works for my big VM host.
>
> OK
No issues here either with just one VM running for testing some
software, so
On Wed, Aug 30, 2023 at 11:07:17PM +, Peter Stuge wrote:
> Stefan Sperling wrote:
> > "Active scan" means the device will send probe requests containing a
> > desired SSID, soliciting immediate probe responses from APs which
> > announce the desired SSID.
>
When I updated iwx to -77 firmware I made a mistake in setting up
the new version of the scan command, in the particular case of
starting a background scan.
One part of the command says that active scan should be used.
"Active scan" means the device will send probe requests containing a
desired
On Fri, Jul 14, 2023 at 02:45:09PM +0800, Kevin Lo wrote:
> In rtwn_tx(), check if the OWN bit of Tx instead of Rx is set.
> Luckily, definitions of R92C_TXDW0_OWN and R92C_RXDW0_OWN are the same.
>
> ok?
ok stsp
> Index: sys/dev/pci/if_rtwn.c
>
On Fri, Jul 07, 2023 at 12:26:16PM +0200, Tobias Heider wrote:
> For bigger changesets I have started experimenting with using got.
> I don't like to have the whole tree on disk twice so I keep my got and CVS
> checkouts in the same directory.
Curious. I am not sure how well that will work in
On Tue, Jun 27, 2023 at 10:55:04AM +0200, Reyk Floeter wrote:
> Hi,
>
> the following diff adds the Intel Wi-Fi 6 0x51f1 device, found in a
> new Thinkpad X1 Carbon Gen 11.
>
> iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX211" rev 0x01, msix
> iwx0: hw rev 0x370, fw 77.f92b5fed.0, pnvm
On Thu, Apr 27, 2023 at 01:38:04PM +0800, Kevin Lo wrote:
> Hi,
>
> The diff below adds initial support for RTL8188FTV adapters.
> RTL8188FTV is an 802.11b/g/n, 1T1R chipset.
> The firmware file comes from Linux's rtl8188fufw.bin [1].
>
> Tested with Comfast CF-WU710N v4 on amd64.
>
> Test
On Mon, Apr 24, 2023 at 05:32:28AM -0600, bent...@openbsd.org wrote:
> Hi,
>
> The AX88179A, which has the same product ID as AX88179, shows up as axen(4),
> but doesn't work:
>
> "axen0: invalid buffer(pkt#1), continue"
> https://marc.info/?l=openbsd-bugs=164832882524713=2
>
> gerhard@ sent a
The iwm_updatechan and iwx_updatechan callbacks are not reachable
because they were never wired up. Only the iwn driver already has
this callback pointer set as intended.
With the patch below iwm/iwx should get triggered when an AP switches
between 20MHz and 40/80MHz channel width, as indicated
On Sun, Mar 26, 2023 at 05:17:36PM +1100, Jonathan Gray wrote:
> there is no need to sync with FreeBSD
ok stsp
> Index: sys/dev/ic/ath.c
> ===
> RCS file: /cvs/src/sys/dev/ic/ath.c,v
> retrieving revision 1.123
> diff -u -p -r1.123
On Thu, Mar 16, 2023 at 08:51:30AM +1100, Jonathan Gray wrote:
> It will be a day or two until I can set everything up again.
> If this works for you I think you should commit it. ok jsg@
Done, thanks!
On Wed, Mar 15, 2023 at 09:18:25AM +1100, Jonathan Gray wrote:
> On Tue, Mar 14, 2023 at 01:37:28PM +0100, Stefan Sperling wrote:
> > On Tue, Mar 14, 2023 at 12:19:10PM +, Klemens Nanni wrote:
> > > Here is an yet untested WEP removal diff based on 'grep WEP' in case we
On Tue, Mar 14, 2023 at 12:19:10PM +, Klemens Nanni wrote:
> Here is an yet untested WEP removal diff based on 'grep WEP' in case we go
> this way rather than fixing WEP.
Did you test wether adding the WEP capability flag to the driver is
sufficient? If you have a hostap-capable interface
On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
> Below is my work-in-progress diff to update iwx(4) to latest firmware.
> Every system tracking -current should already have the new -77 firmware
> images.
>
> The new images contain security fixes of (to me) u
Below is my work-in-progress diff to update iwx(4) to latest firmware.
Every system tracking -current should already have the new -77 firmware images.
The new images contain security fixes of (to me) unknown severity.
Unfortunately there have been quite a number of firmware API changes since
our
On Fri, Jan 13, 2023 at 09:18:30PM +0100, Mathias Koehler wrote:
> Ehm well it should look like this, sorry:
This code duplication has now been removed. Thanks!
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving
On Sun, Jan 01, 2023 at 10:37:44PM +, Ali Farzanrad wrote:
> OK, I started in a working state where I was connected to my Android
> phone:
OK, let's untangle this... see below...
> # cat /etc/hostname.athn0
> nwid [..name..] wpakey [..pass..]
> inet autoconf
Before you get to "status:
On Sun, Jan 01, 2023 at 09:00:30PM +, Ali Farzanrad wrote:
> Hi Stefan,
>
> Stefan Sperling wrote:
> > On Sun, Jan 01, 2023 at 05:00:35PM +, Ali Farzanrad wrote:
> > > Hi tech@,
> > >
> > > Happy new year!
> > > I have some weird pr
On Sun, Jan 01, 2023 at 05:00:35PM +, Ali Farzanrad wrote:
> Hi tech@,
>
> Happy new year!
> I have some weird problems with my athn interface which drives me crazy.
>
> 1. Whenever I configure my athn as `media auto' for the first time it
> correctly detects correct media subclass, but as
One of my 80MHz 11ac APs transmits beacons on several channels,
while indicating its actual primary channel in the HT operation
information element (HT OP IE). We currently ignore the primary
channel given in the HT OP IE, and this leads to a problem.
(We do read the AP's idea of its primary
If authentication to the AP times out iwx(4) currently triggers a
fatal firmware error while resetting the device.
As part of configuring the device for operation, we create a "binding"
between a MAC config and a PHY config in firmware.
And before we start to associate, firmware is given a "time
iwm(4) can panic if the firmware image is missing or corrupt:
starting network
iwm1: firmware parse error 22, section type 0
iwm1: failed to load init firmware
ifconfig: SIOCSIFXFLAGS: Invalid argument
panic: kernel diagnostic assertion "sc->task_refs.r_refs == 0" failed: file "/u
On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote:
> pluggable?
It really is a very machine-specific question. It depends
on how the manufaturer decided to connect devices to the
mainboard, which is not always possible to tell from the
perspective of software which runs on the
On Thu, Sep 01, 2022 at 08:31:04PM +, Klemens Nanni wrote:
> This is practically the same diff we already landed for arm64.
>
> The kernel already supports booting off 1C and with tech@'s
> "installboot: sparc64: fix -r on multi-chunk softraid chunk" diff the
> install process will no longer
Use raid1c-specific meta-data while looking for a key disk that
belongs to a RAID 1C volume.
By dumb luck this is only a cosmetic issue, because struct layout
happens to put the field in the same place.
ok?
diff a87e94ce1617958c99b63ed0a056e46650a27375
ba39970f6365aeeb1b486101f6573c60b7f88573
On Fri, Aug 12, 2022 at 09:41:59AM +, Klemens Nanni wrote:
> Here's the adapted diff for arm64 minus manual bits to avoid churn for
> now.
>
> installboot(8) needs softraid(4) support (see my diff on tech@), but
> besides that, root on passphrase 1C softraid on arm64 works as expected:
>
>
On Thu, Aug 11, 2022 at 03:51:17PM +, Klemens Nanni wrote:
> Booting off softraid on arm64 is supported but installboot(8) has no
> softraid(4) support on arm64.
>
> This means installboot always copies the single bootstrap efiboot on the
> root volume and completely ignores softraid chunks,
On Fri, Aug 12, 2022 at 07:28:57PM +0200, Stefan Sperling wrote:
> On Fri, Aug 12, 2022 at 03:20:40PM +0200, Stefan Sperling wrote:
> > I am currently trying to find time in order to test my patch on
> > real hardware. Any additional testing would be very welcome.
>
> I foun
On Fri, Aug 12, 2022 at 03:20:40PM +0200, Stefan Sperling wrote:
> I am currently trying to find time in order to test my patch on
> real hardware. Any additional testing would be very welcome.
I found time :)
Tested on real hardware with 4 disks.
Both biosboot and UEFI boot are w
On Fri, Aug 12, 2022 at 02:28:30PM +0200, Erling Westenvik wrote:
> On Thu, Aug 04, 2022 at 07:26:23PM +0200, Stefan Sperling wrote:
> > This adds support for booting from RAID 1C volumes on amd64.
>
> This is so cool and I can't wait to get a chance to try it out!
>
> >
This adds support for booting from RAID 1C volumes on amd64.
Only boot-loader changes are needed. Both installboot(8) and
the kernel already do what is required to make this work.
I have tested with biosboot in vmm. The changes involved are trivial,
and I am modifying copies of the same code
On Mon, Aug 01, 2022 at 03:38:59PM +0200, Omar Polo wrote:
> there's an edge case in locate_hunk with empty files; if `first_guess'
> is zero then main() assumes that locate_hunk has failed and aborts the
> patch operation. Instead, make sure to return 1 (the line number) so
> that the patch
On Mon, Aug 01, 2022 at 12:48:16PM +0200, Omar Polo wrote:
> i was looking for a different issue in patch when i found this.
> patch(1) fails to recognize the reversal application of a patch that
> creates a file (this is test t3).
>
> since an empty context always matches, the idea is to run the
On Sat, Jul 16, 2022 at 08:26:49AM +0200, Stefan Hagen wrote:
> Hi,
>
> This is a workaround taken from Linux to mitigate sporadic cursor jumps
> due to a firmware bug. Known affected laptops are:
>
> - Lenovo Thinkpad X13 Gen1 (AMD version)
> - Lenovo Thinkpad T14s (AMD version)
> - Lenovo A475
On Thu, Jul 14, 2022 at 10:57:51AM +0200, Claudio Jeker wrote:
> On Thu, Jul 14, 2022 at 10:51:42AM +0200, Stefan Sperling wrote:
> > Perhaps also consider moving counters to netstat -s instead of ifconfig.
>
> I don't think netstat -s is a good place for per peer stats (neithe
On Wed, Jul 13, 2022 at 05:13:49PM +, Mikolaj Kucharski wrote:
> On Wed, Jul 13, 2022 at 05:43:59PM +0100, Stuart Henderson wrote:
> > >
> > > Not sure how to handle long output in different way. If you don't
> > > specify wgdesc to the ifconfig, the diff doesn't change anything and
> > >
On Wed, Jul 13, 2022 at 02:18:53PM +0200, Otto Moerbeek wrote:
> Hi,
>
> after a prompt from stsp@ and florian@, reporting that newfs_msdos
> fails when given an $duid.i argument, I set down to see what could be
> going on. My test using an USB stick failed to reprdouce the problem.
> Then I
On Mon, Jul 11, 2022 at 03:13:58PM -0400, Farhan Khan wrote:
> On Mon, Jul 11, 2022, at 2:24 PM, Stefan Sperling wrote:
> Thank you so much for your prompt reply!
>
> > In AP mode, max nodes effectively sets a limit on how many clients can
> > be connected concurrently
On Mon, Jul 11, 2022 at 11:32:12AM -0400, Farhan Khan wrote:
> Hi all,
>
> I am reading through the athn(4) driver and see a reference to
> ieee80211com.ic_max_nnodes here
> (http://bxr.su/OpenBSD/sys/dev/ic/athn.c#294). What is this variable? The
> comment immediately above says "In HostAP
On Sun, Jun 26, 2022 at 07:48:46PM +1000, Jonathan Gray wrote:
> sta.rssi is later used which is 'Fields valid for ver >= 4'
> but it seems with the earlier zeroing the use here should be fine?
Thanks! I missed that.
Testing suggests it makes more sense to keep the RSSI value which
was
There is an off-by-one in bwfm_update_node(). This function reads
the tx_rate field from station information returned by firmware.
According to a comment in the Linux driver, this field is valid
for sta_info command versions >= 3.
On Mon, May 09, 2022 at 08:17:35PM +, molotov31337 wrote:
> I recently picked up a Panda Wireless PAU06 and got it working, can this be
> committed?
> Here is the cvs diff
Committed, thanks!
> Index: usbdevs
> ===
> RCS file:
As noticed by jsg@ and kevlo@ we use a bad MAC address on AX210 devices.
Patch below fixes the issue on AX210, and still works on AX200.
The old way of reading the MAC no longer works on AX210; apparently this
new way of reading the MAC was introduced in the 9k hw generation but the
old way was
This patch adds support for AX210/AX211 devices to iwx(4).
While this patch attempts to make a couple of devices work which
are part of this device family, so far only one specific AX210
device has been tested:
iwx0 at pci4 dev 0 function 0 "Intel Wi-Fi 6 AX210" rev 0x1a, msix
iwx0: hw rev
On Sun, May 08, 2022 at 12:29:57AM -0400, Farhan Khan wrote:
> On May 6, 2022 4:37:48 AM EDT, Stefan Sperling wrote:
> >On Thu, May 05, 2022 at 01:19:08PM -0400, Farhan Khan wrote:
> >> Hi all,
> >>
> >> Summary Question:
> >>
> >> Broadly
On Thu, May 05, 2022 at 01:19:08PM -0400, Farhan Khan wrote:
> Hi all,
>
> Summary Question:
>
> Broadly, I am trying to understand where a interrupt callback is specified if
> not already specified by usbd_open_pipe_intr(9). Specifically, for the
> athn(4)
> driver, I am trying to understand
On Sat, Apr 09, 2022 at 05:46:29PM +0200, Sven Wolf wrote:
> Hi Stefan,
>
> thanks for your effort.
> I've successfully tested your latest patch.
> I also got the sw_hw_rev:
>
> sc_hw_rev=354
Thank you! Now everything makes sense :)
On Sat, Apr 09, 2022 at 04:53:50PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 04:52:12PM +0200, Stefan Sperling wrote:
> > On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> > > As sthen points out, please show sc_hw_rev without any of its bit
On Sat, Apr 09, 2022 at 04:52:12PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> > As sthen points out, please show sc_hw_rev without any of its bits
> > masked out, with a patch like this:
>
> Nevermind, I found a bug i
On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> As sthen points out, please show sc_hw_rev without any of its bits
> masked out, with a patch like this:
Nevermind, I found a bug in my patch which most certainly
breaks your device.
Please try this on top of the patch I se
On Sat, Apr 09, 2022 at 03:28:14PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 12:47:56PM +0200, Sven Wolf wrote:
> > Hi Stefan,
> >
> > sorry, I'm not sure how I can get the sc_hw_rev value.
> > Hopefully this is the requested value:
> >
> > i
On Sat, Apr 09, 2022 at 12:47:56PM +0200, Sven Wolf wrote:
> Hi Stefan,
>
> sorry, I'm not sure how I can get the sc_hw_rev value.
> Hopefully this is the requested value:
>
> iwx0: hw rev 0x350, fw ver 67.8f59b80b.0
This is not the "QuZ" (0x354) hardware revision.
However, Linux obviously
On Sat, Apr 09, 2022 at 03:26:03AM +0200, stolen data wrote:
> It's been great seeing iwm/iwn/iwx/athn getting a lot of updates lately. I
> wonder if there's any work planned for getting 11n support to some of the
> older but still capable Realtek chipsets in ral(4)?
>
> I have a spare
_INTEL_WL_22500_8:
> if (sc->sc_hw_rev != IWX_CSR_HW_REV_TYPE_QUZ)
Thanks Sven!
What is the value of sc_hw_rev on this 0x4df0 device?
> sc->sc_fwname = IWX_QU_B_HR_B_FW;
> else
> --- 9859,9864
>
>
> Thanks,
>
On Tue, Jan 11, 2022 at 10:33:39PM +, Iraklis Karagkiozoglou wrote:
> Hello Stefan,
>
> I tried to port the firmware detection and config values
> from iwlwifi.
>
> On iwx_cfg_trans_params and iwx_cfg structs I ported only
> the fields iwx_attach was setting based on the iwx_device.
>
>
On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote:
> This diff adds preliminary support for RTL8156B to ure(4) and
> bug fixes for RTL8153/RTL8156.
>
> Tested:
> ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB 10/100/1G/2.5G
> LAN" rev 3.20/31.00 addr 3
> ure0: RTL8156B
On Sun, Mar 20, 2022 at 05:00:13PM -0600, Thomas Frohwein wrote:
> I updated the diff for the controller with your diff. Below is the
> complete diff for all the files involved. I tested it again with my
> controller and sdl-jstest (in ports); it continues to work as intended.
>
> ok?
Thanks! Ok
This patch fixes a couple of issues in the VHT rate adaptation code,
and with the data which iwm(4) is feeding into it.
Testing 11ac mode from a distance to my AP, I found that iwm(4) tends
to pick a Tx rate which is too high, resulting in too much of a drop
in throughput.
With this patch,
On Fri, Jan 15, 2021 at 06:32:04AM -0700, Thomas Frohwein wrote:
> @@ -557,6 +571,23 @@ uhidev_open(struct uhidev *scd)
> DPRINTF(("uhidev_open: couldn't allocate owxfer\n"));
> error = ENOMEM;
> goto out3;
> + }
> +
> +
Both iwm and iwx are currently writing VHT capabilities into
the "common" secion of the firmware's probe request frame template.
This "common" section is used on both 2GHz and 5GHz bands.
Announcing VHT capabilities on 2GHz makes no sense.
Move them into the 5GHz-only section.
ok?
diff
On Sat, Mar 19, 2022 at 05:32:48PM +0100, Stefan Sperling wrote:
> The net80211 input routine expects that ic->ic_bss->ni_chan will always
> correspond to the channel which is currently being scanned. This dates
> back to older devices which are manually tuned to the next channel
The net80211 input routine expects that ic->ic_bss->ni_chan will always
correspond to the channel which is currently being scanned. This dates
back to older devices which are manually tuned to the next channel by the
driver during SCAN->SCAN state transitions. And this must of course be
kept
On Fri, Mar 18, 2022 at 11:36:50AM +0100, Stefan Sperling wrote:
> On Fri, Mar 18, 2022 at 05:25:42AM +0100, Landry Breuil wrote:
> > interestingly, when associated over ac to the livebox the background
> > scans only shows the 5ghz channels from both APs, but when im associated
&g
Fix number 1:
During network selection (for 'ifconfig join'), give APs which support
11n and 11ac a higher score. VHT implies HT, so 11ac networks receive
2 additional points while 11n-only networks receive one additional point.
Fix number 2:
During AP selection within a given network, we would
I botched the logic used by a check in iwm_vht_single_rate_control().
ok?
diff 15b71cdf8530b1f64fb85d50873b1ff1fad3f0e8 /usr/src
blob - 2c01f718d47acb01a227795fef659ef353f5c7f6
file + sys/dev/pci/if_iwm.c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -5550,7 +5550,7 @@
On Wed, Mar 16, 2022 at 10:03:36PM +0100, Stefan Sperling wrote:
> On Wed, Mar 16, 2022 at 08:46:01PM +0100, Jeremie Courreges-Anglas wrote:
> > On Mon, Mar 14 2022, Stefan Sperling wrote:
> > > It is currently impossible to use more than one iwm or iwx interface
> > >
On Fri, Mar 18, 2022 at 01:39:01PM +0100, Marcus MERIGHI wrote:
> Hello,
>
> s...@stsp.name (Stefan Sperling), 2022.03.17 (Thu) 21:09 (CET):
> > On Thu, Mar 17, 2022 at 07:02:06PM +0100, Marcus MERIGHI wrote:
> > > s...@stsp.name (Stefan Sperling), 202
On Fri, Mar 18, 2022 at 05:25:42AM +0100, Landry Breuil wrote:
> interestingly, when associated over ac to the livebox the background
> scans only shows the 5ghz channels from both APs, but when im associated
> to my regular AP the background scans shows both 2ghz and 5ghz chans.
> not sure that
On Thu, Mar 17, 2022 at 02:43:14PM -0700, Mike Larkin wrote:
> On Wed, Mar 16, 2022 at 11:17:47PM +0100, Stefan Sperling wrote:
> > On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote:
> > > This patch adds initial 11ac support to the iwm(4) driver.
> > &
On Thu, Mar 17, 2022 at 07:02:06PM +0100, Marcus MERIGHI wrote:
> Hello!
>
> Thanks for your work on this!
>
> s...@stsp.name (Stefan Sperling), 2022.03.16 (Wed) 16:11 (CET):
> > This patch adds initial 11ac support to the iwm(4) driver.
> > It allows use of
On Thu, Mar 17, 2022 at 01:07:42AM +, Stuart Henderson wrote:
> 802.11 flags=0<>: beacon, ...
> 191:12 0xb109cb33aaff1806aaff1806, 192:5 0x00aaff,
Now is probably a good time to start pretty-printing these fields in tcpdump.
ok?
diff 140ae54c8a573c04824dd96957ebff4e069b2dfd /usr/src
On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwm(4) driver.
> It allows use of 80 MHz channels and VHT MCS.
Updated patch. Fixes a fatal firmware error on devices which
do not support MIMO, such as the 3160.
diff refs/heads/
On Wed, Mar 16, 2022 at 08:46:01PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 14 2022, Stefan Sperling wrote:
> > It is currently impossible to use more than one iwm or iwx interface
> > in a system because I don't understand C.
> >
> > Trying to bring up
This patch adds initial 11ac support to the iwm(4) driver.
It allows use of 80 MHz channels and VHT MCS.
In net80211 I added a new rate control module to support VHT rates, as
a new file called ieee80211_ra_vht.c, derived from ieee80211_ra.c which
we use in 11n mode. The task of this code is to
It is currently impossible to use more than one iwm or iwx interface
in a system because I don't understand C.
Trying to bring up an uninitialized interface anyway results in a
kernel panic ("bogus channel pointer" from net80211), so prevent
the device from being used in case we never managed to
On Thu, Mar 10, 2022 at 01:56:19PM -0500, Dave Voutila wrote:
>
> Stefan Sperling writes:
>
> > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> >> Unless anyone else finds a problem, this patch can be considered ready
> >> for review and co
On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> Unless anyone else finds a problem, this patch can be considered ready
> for review and commit.
Of course, I forgot to apply my sysassert fix to the second phy context
command function... Fixed here.
diff refs/heads/maste
On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwx(4) driver.
> This means that 80MHz channels can be used. No other 11ac features
> are enabled yet.
>
> This is not yet a patch which could be committed. Apart from
On Wed, Mar 09, 2022 at 07:16:41PM +0300, Mikhail wrote:
> On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> > /*
> > + * Install received VHT caps information in the node's state block.
> > + */
> > +void
> > +ieee80211_setup_vhtcaps(struct
This patch adds initial 11ac support to the iwx(4) driver.
This means that 80MHz channels can be used. No other 11ac features
are enabled yet.
This is not yet a patch which could be committed. Apart from debug
prints which need to go, there is a known issue found by dv@ where
this patch causes a
On Tue, Mar 08, 2022 at 02:38:39PM -0700, Theo de Raadt wrote:
> Stefan Sperling wrote:
> > In this case it is not ifconfig, but netstat -W iwm0.
> > Which is a debugging tool, like netstat -s.
>
> We don't care when netstat breaks
Alright, then this diff is indeed not necessary.
On Tue, Mar 08, 2022 at 12:58:27PM -0700, Theo de Raadt wrote:
> Claudio Jeker wrote:
>
> > Honestly I think this is overkill. There is no stat struct where we do
> > this dance. It is accepted that netstat needs to keep in sync for these
> > structs to work. Why is it necessary to disconnect
On Tue, Mar 08, 2022 at 03:55:48PM +0100, Stefan Sperling wrote:
> On Mon, Mar 07, 2022 at 03:04:06PM -0700, Theo de Raadt wrote:
> > > For now, the structs are identical so the code copying data out is
> > > kept simple.
> >
> > I think this is unwise, and yo
On Mon, Mar 07, 2022 at 03:04:06PM -0700, Theo de Raadt wrote:
> > For now, the structs are identical so the code copying data out is
> > kept simple.
>
> I think this is unwise, and you should write the field-by-field copying
> function at the same time, otherwise this is just asking for
There is another net80211 ioctl which shares a struct between kernel
and userland: struct ieee80211_stats shown by the netstat -W command.
While it is trivial to recompile netstat when this struct is changed,
giving the kernel a separate struct type would allow us to add, change,
or remove
On Tue, Mar 01, 2022 at 10:41:14AM +, Stuart Henderson wrote:
> Probably best to wait a bit for other feedback, but: OK sthen
Ok from me, too. Some of my subnets are routed to me via OpenVPN so
I will be forced to keep using it for the foreseeable future.
I have $openvpn_port variables in
On Mon, Feb 21, 2022 at 10:20:17AM +0100, Marc Espie wrote:
> On Mon, Feb 21, 2022 at 05:36:16PM +0900, Yuichiro NAITO wrote:
> > Of course, all programs compiled without '-pg' work fine for me.
> > I found this issue when I profile my application with gprof(1).
> > For example, following example
On Tue, Jan 25, 2022 at 11:22:45AM +0100, Mark Kettenis wrote:
> > The KASSERT triggers but for the wrong reason: We don't have outstanding
> > tasks, we have a bad reference counter. Only setting the ref counter to 1 if
> > we are about to launch a task during resume should fix it, and this
On Tue, Jan 25, 2022 at 09:32:21AM +0100, Mark Kettenis wrote:
> Happened again while still on a Jan 16 snapshot kernel. So it is not
> related to that diff.
>
> Here is the panic message and backtrace:
>
> panic: kernel diagnostic assertion "sc->task_refs.refs == 0" failed: file
>
On Sun, Jan 16, 2022 at 07:38:11PM +0100, Mark Kettenis wrote:
> > Date: Sun, 16 Jan 2022 19:28:06 +0100
> > From: Stefan Sperling
> >
> > On Sun, Jan 16, 2022 at 03:50:55PM +0100, Mark Kettenis wrote:
> > > However, running this diff I had a problem after resu
On Sun, Jan 16, 2022 at 03:50:55PM +0100, Mark Kettenis wrote:
> However, running this diff I had a problem after resuming my laptop
> twice. After resume the interface didn't work and I found the
> following in dmesg:
>
> iwm0: could not initialize hardware
>
> I tried to reset the interface by
On Sun, Jan 16, 2022 at 05:51:03PM +0300, Alex Beakes wrote:
> FreeBSD has tested iwlwifi with Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420.
> Wifi 6E, ty-a0-gf-a0-63.ucode.
>
> Is there a way of implementing this and making the wifi module work.
>
> https://wiki.freebsd.org/WiFi/Iwlwifi
I will
1 - 100 of 1452 matches
Mail list logo
