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 u
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
v/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 + d157f116c025d882f1ec8df84b4c3deca3ca340f (mode 644)
--- /dev/null
+++ sys/dev/pci/if_dwqe_pci.c
@@ -0,0 +1,154 @@
+/* $OpenBSD$ */
+
+/*
+ * Co
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 doesn'
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 (PCI_PRODUCT(pa->pa
ixl
+# 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
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
> > po
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 BI
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 mo
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 SS
drive=cdinst
That depends on your seabios having support for virtio cdroms. Not sure
if that is the default by now.
Or maybe try a SATA cdrom, but you would need to figure out the qemu
options for that yourself.
Oh, and the exact qemu version you used may be interesting for people
trying to
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 prac
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 e4a4953
Fix handling of feature bits >= 32. This does not yet affect any driver
as no high feature bit besides VERSION_1 is used, and that one has special
handling.
Also, with VIRTIO_DEBUG, simply walk through all transport and device
feature names, so that we don't need to adjust the if clause whenev
>From FreeBSD commits
commit c0db7289c3de290d821311942d5533f2284af77f
Author: pfg
Date: Wed Aug 8 15:08:22 2018 +
msdosfs: fixes for Undefined Behavior.
and
commit 852150953b828e4e8c32789637061001158a8cf4
Author: kib
Date: Fri
I forgot to mention that no stress test is necessary. If it boots and
the virtio devices work at all, that should be enough.
Cheers,
Stefan
Am 20.05.23 um 15:00 schrieb Stefan Fritsch:
Hi,
with help from Aaron Mason, I have found the problem responsible for the
vioscsi panic on oracle cloud
on amd64 / qemu. I would be interested in test
results on other systems, especially on top of vmd and on arm64 with
viogpu.
Aaron, can you please also test with the updated diff?
Thanks in advance.
Cheers,
Stefan
commit d3209e34d77ab7353973efb2a57303f636fff4f4
Author: Stefan Fritsch
Date
On Thu, 4 May 2023, Aaron Mason wrote:
> On Mon, May 1, 2023 at 4:56 AM Stefan Fritsch wrote:
> >
> > Hi,
> >
> > what qemu version are you using? I cannot reproduce this with qemu 7.2.
> > Can you try with a newer qemu?
> >
> > Cheers,
> &g
Dropping misc@ from cc
Am 01.05.23 um 02:08 schrieb Aaron Mason:
I can reproduce it with this in QEMU 8.0 in Winders (thanks Antun who
sent something like this to the bugs@ list):
qemu-system-x86_64 -accel whpx,kernel-irqchip=off -machine q35 \
-cpu EPYC-Rome,-monitor -m 8g -smp 6,sockets=1
Hi,
what qemu version are you using? I cannot reproduce this with qemu 7.2.
Can you try with a newer qemu?
Cheers,
Stefan
Am 25.04.23 um 14:53 schrieb Aaron Mason:
Yeah I'm getting the same thing. Trying a build in QEMU and
transferring in to see if that helps. Will report back.
Ok,
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 repor
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&m=164832882524713&w=2
>
> gerhard@ sent
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 by
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 a
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'
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 like
Stefan Hagen wrote (2023-03-05 09:19 CET):
> Alexandre Ratchov wrote (2023-03-05 08:53 CET):
> > If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please
> > test this diff and report regressions. Especially audio lock ups that
> > require reboot.
Matthieu Herrb wrote (2023-02-27 21:17 CET):
> Hi,
>
> the patch below update the amdgpu(4) X.Org driver to version 23.0.0
>
> To test (on machines with an AMD / Radeon GPU)
>
> # cd /usr/xenocara/driver/xf86-video-amdgpu
> # patch -p0 -E < /path/to/this/file
> # make -f Makefile.bsd-wrapper ob
Alexandre Ratchov wrote (2023-03-05 08:53 CET):
> If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please
> test this diff and report regressions. Especially audio lock ups that
> require reboot.
>
> IIRC, MSI was disabled few years ago to "fix" such lockups, and now
> this diff suggest
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 l
rest of the
FreeBSD fix to OpenBSD. This seems to fix the issue.
Are there any heavy users of msdosfs who can give this a test? Or any
comments or oks?
Cheers,
Stefan
diff --git a/sys/msdosfs/msdosfs_fat.c b/sys/msdosfs/msdosfs_fat.c
index c15b6257d43..0ab1463ea67 100644
--- a/sys/msdosfs/msdos
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 revis
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: active
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 so
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 chann
Hi,
I'd like to add the mime magic for the Apple heic/heif formats,
which are used by Apple devices in recent years to store media.
This format family can contain still images, short sequences
(live photos) and videos.
The rules are taken from FreeBSD.
OK?
Best Regards,
Stefan
Index: us
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 e
Ross L Richardson wrote (2022-12-18 10:55 CET):
> The word "array" occurs only once in sh.1. Therefore, either it deserves
> more explanation, or removal with something like the patch below.
I think you're right. This looks like an oversight from the works when
sh(1) was rewritten / split from k
#x27;t think the scale values can be read from the device.
But you can get them from the linux wacom driver here:
https://github.com/linuxwacom/input-wacom/blob/master/4.5/wacom_wac.c#L11
Untested patch below.
Best Regards,
Stefan
diff --git a/sys/dev/usb/uwacom.c b/sys/dev/usb/uwa
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
sr/src/sys/dev/p
r two days now. With several
kernel builds and regular desktop use (browsers and such).
Best Regards,
Stefan
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 machine
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 f
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, s
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 work
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!
>
>
18,7 @@ extern int
pf_tbladdr_setup(struct pf_ruleset *,
struct pf_addr_wrap *, int);
extern void pf_tbladdr_remove(struct pf_addr_wrap *);
extern void pf_tbladdr_copyout(struct pf_addr_wrap *);
-extern void pf_calc_skip_steps(struct pf_rulequeue *);
+extern void pf_calc_skip_steps(struct pf_ruletree *);
extern void pf_purge_expired_src_nodes(void);
extern void pf_purge_expired_states(u_int32_t);
extern void pf_purge_expired_rules(void);
@@ -1744,7 +1749,7 @@ extern voidpf_print_state(struct
pf_state *);
extern void pf_print_flags(u_int8_t);
extern void pf_addrcpy(struct pf_addr *, struct pf_addr *,
sa_family_t);
-voidpf_rm_rule(struct pf_rulequeue *,
+voidpf_rm_rule(struct pf_ruletree *,
struct pf_rule *);
voidpf_purge_rule(struct pf_rule *);
struct pf_divert *pf_find_divert(struct mbuf *);
Best Regards,
Stefan Butz
smime.p7s
Description: S/MIME cryptographic signature
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 acros
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 opera
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 ver
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 (n
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
> > > ifco
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 start
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 mod
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 discovered
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.
linux/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.
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: /c
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 st
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 0x420,
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 bits
> &
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:
> >
> &
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 re
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 RT2860+RT28
On Sat, Apr 09, 2022 at 12:31:09AM +0200, Sven Wolf wrote:
> Hi Stefan,
>
> on my device WL_22500_8 0x4df0 this patch doesn't work directly.
> I get the error message:
> iwx0: could not load firmware, 35
> iwx0: failed to load init firmware
>
> Under Linux the
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 ba
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 (0x7
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, iwm(4)
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 f6c92c11f
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 workin
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 li
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 @@ iwm_vht_single_rate_
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), 2022.03.16 (Wed) 1
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 ma
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
blo
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 bri
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 de
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 i
1 - 100 of 1029 matches
Mail list logo
