On Sat, 2 Aug 2025, T.J.Newton wrote:
Hi,
I am particularly interested in the LinuxKPI USB support for the RTW8821CU
chipset.
This chipset is mention in the https://wiki.freebsd.org/WiFi/Rtw88, section
"USB Support". The same paragraph states: "I have most of the changes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #8 from Vishal Paudel ---
(In reply to Bjoern A. Zeeb from comment #6)
Ok all the best. Meanwhile, I will try fiddling around in the console with the
wifi-less freebsd 15-LATEST installation.
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #7 from Vishal Paudel ---
Created attachment 262136
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=262136&action=edit
A photo of the "[manual]" option WIFI rtw880 related Kernel Panic on 15-LATEST
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #6 from Bjoern A. Zeeb ---
(In reply to Vishal Paudel from comment #5)
Thanks. That is indeed one for me and not for the installer. Two things to
fix then. I'll get back to you as I get to it.
--
You are receiving this mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #5 from Vishal Paudel ---
(In reply to Bjoern A. Zeeb from comment #3)
I have attached a photo of the Kernel Panic resulting from hitting enter on
"[auto]" option on rtw88 on the wifi page on the freebsd install
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #4 from Vishal Paudel ---
Created attachment 262135
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=262135&action=edit
A photo of the WIFI rtw880 related Kernel Panic on 15-LATEST
--
You are receiving this mail becau
;installer crashes" and you end up at the debugger prompt, you
mean the kernel panics? In that case maybe post a screenshot here first (if
you cannot transcribe or don't have a serial console, try a photo) and we can
see if it is also rtw88 related; if not we'll redirect it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288186
--- Comment #2 from Vishal Paudel ---
Yes, I would be willing to test any patches to this issue in 15-CURRENT.
I am ready to provide further info about this issue. Right now the only insight
I have is that the installer crashes and falls t
Summary|RTW880 wireless not working |rtw88 not working with
|during installation |"unknown channel 234!!"
||during installation
Blocks||273621
--- Comment #1 from Bjoern A. Zee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283142
--- Comment #31 from Bjoern A. Zeeb ---
*** Bug 284202 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273621
[Bug 273621] rtw88, rtw89 meta-bug
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283142
--- Comment #30 from Kurt Jaeger ---
tested on 14.3-BETA1, wlan works 8-)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286549
--- Comment #2 from Bjoern A. Zeeb ---
Please update to stable/14 or 14.3-BETA1. Anything with 14.2-R no matter what
patch level will not assoc.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283142
Bjoern A. Zeeb changed:
What|Removed |Added
CC||p...@freebsd.org
--- Comment #29
;t catch.
But SW_MGMT_TX is not supported on FreeBSD and should not show up;
seems rtw88 just unconditionally returns it. I'll quiten this sometime
next week.
Should be fixed now in main.
Lots of health,
/bz
--
Bjoern A. Zeeb r15:7
BSD and should not show up;
seems rtw88 just unconditionally returns it. I'll quiten this sometime
next week.
Thanks for reporting!
/bz
--
Bjoern A. Zeeb r15:7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Bjoern A. Zeeb changed:
What|Removed |Added
Resolution|--- |FIXED
Flags|needs_er
|--- |FIXED
Flags|needs_errata? |
--- Comment #28 from Bjoern A. Zeeb ---
With the little problem reports, two actual fixes needed to make rtw88 work
well enough, and releng/14.3 being around the corner starting in a month, the
risk for a EN might be
On 3/5/25 22:06, Bjoern A. Zeeb wrote:
Currently firmware is still in sys/ but will be removed soon-ish.
That explains.
#fwget
Needed firmware packages: 'gpu-firmware-intel-kmod-geminilake wifi-
firmware-iwlwifi-kmod-9000'
pkg: No packages available to install matching 'wifi-firmware-
iw
On Wed, 5 Mar 2025, Andrea Venturoli wrote:
On 2/27/25 15:28, Andrea Venturoli wrote:
The warning about "iwl-debug-yoyo.bin" always happens, with our without the
latest commits.
Hello again.
Just another curiosity.
I've never installed a firmware for iwlwifi; however I've seen in another
t
On 2/27/25 15:28, Andrea Venturoli wrote:
The warning about "iwl-debug-yoyo.bin" always happens, with our without
the latest commits.
Hello again.
Just another curiosity.
I've never installed a firmware for iwlwifi; however I've seen in
another thread that I should perhaps use fwget.
#fwg
Hi, sorry for being late to the party.
On 2/27/25 23:54, Bjoern A. Zeeb wrote:
(4) rtw89 (my own testing):
* vendor=0x10ec device=0xc822 subvendor=0x1a3b subdevice=0x3750
[8852AE, rtw89/rtw8852a_fw.bin 0.13.36.0 (c33d3f88)]
Problems, 'FW crash'
On Mon, Mar 3, 2025 at 2:35 PM Bjoern A. Zeeb wrote:
> On Mon, 3 Mar 2025, Kevin Oberman wrote:
>
> > I have only the choice between WPA-PSK and WPA-Default Password. For
> 2.4G,
> > I also can select WEP or Off. I also have a choice between WPA2 and
> > WPA/WPA2 when WPA is selected. Looks like
On Mon, 3 Mar 2025, Kevin Oberman wrote:
I have only the choice between WPA-PSK and WPA-Default Password. For 2.4G,
I also can select WEP or Off. I also have a choice between WPA2 and
WPA/WPA2 when WPA is selected. Looks like I'm stuck for hte time being. I
I assume you are using WPA/WPA2 curr
On Mon, Mar 3, 2025 at 3:14 AM Bjoern A. Zeeb wrote:
> On Sun, 2 Mar 2025, Kevin Oberman wrote:
>
> > On Sun, Mar 2, 2025 at 4:56 PM Bjoern A. Zeeb wrote:
> >
> >> On Sun, 2 Mar 2025, Kevin Oberman wrote:
> >>
> >> Hi Kevin,
> >>
> >>> I was excited to see that it looked like 802.11n was on the
On Sun, 2 Mar 2025, Kevin Oberman wrote:
On Sun, Mar 2, 2025 at 4:56 PM Bjoern A. Zeeb wrote:
On Sun, 2 Mar 2025, Kevin Oberman wrote:
Hi Kevin,
I was excited to see that it looked like 802.11n was on the way! Tried
step one, enabling 802.11 crypto, and had no luck at all. I know my AX211
On Sun, Mar 2, 2025 at 4:56 PM Bjoern A. Zeeb wrote:
> On Sun, 2 Mar 2025, Kevin Oberman wrote:
>
> Hi Kevin,
>
> > I was excited to see that it looked like 802.11n was on the way! Tried
> > step one, enabling 802.11 crypto, and had no luck at all. I know my AX211
> > supports CCMP, but attemptin
On Sun, 2 Mar 2025, Kevin Oberman wrote:
Hi Kevin,
I was excited to see that it looked like 802.11n was on the way! Tried
step one, enabling 802.11 crypto, and had no luck at all. I know my AX211
supports CCMP, but attempting to boot gets:
wlan0: link state changed to UP
iwlwifi0: _lkpi_iv_key_
s compiled in now it is disabled behind a tunable until
> there is sufficient feedback for iwlwifi, rtw88 and rtw89 that it works.
> Once that happens I'll flip the default for the tunable at least to on
> and eventually remove it alltogether and we can move to the next steps
> of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Bjoern A. Zeeb changed:
What|Removed |Added
Flags|mfc-stable13? |mfc-stable13-,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Mark Linimon changed:
What|Removed |Added
Flags|mfc-stable14? |mfc-stable13?
--- Comment #40 from
On 2/27/25 16:54, Bjoern A. Zeeb wrote:
Hello.
If you can compile yourself, can you (in 14.2 / stable/14 still in
/usr/src (or wherever your source tree is) and then tools/tools/
net80211/wlanstats/
Type make and make install and make sure your shell finds the newly
innstalled program.
wla
n 9xxx made me not do that (yet).
>
> As expected the modern iwlwifi chipset (AX2xx) results seem fine. If
> you will do further testing and have an AX2xx device, please report any
> issues.
> I am very happy that the one rtw88 feeback also was fine.
>
> I want people to unders
On Thu, 27 Feb 2025, Andrea Venturoli wrote:
Hi,
Then I set compat.linuxkpi.80211.hw_crypto=1.
First strange thing: "ifconfig wlan0" output doesn't differ; it' still says
"54Mbps" and "11g".
WiFi doesn't seem to work properly, as I cannot even ssh into the machine
(hangs after some startup me
On 2/19/25 08:17, Andrea Venturoli wrote:
I've seen cherry-picking it is possible with just a few manual
adjustment...
You can certainly do that. And that should work.
It'll likely be easier to cherrypick from stable/ once things are merged
(especially if you keep the merge order).
OK, so
sting and have an AX2xx device, please report any
issues.
I am very happy that the one rtw88 feeback also was fine.
I want people to understand that if they want HT/VHT support to work
(later) on their device by default with the LinuxKPI based drivers we
need to make sure hw crypto works without tr
Hello,great news, thank you for your hard work! Here are mine results. It's working but not how it was actually expecting :). It connected in mode 11a (was 11g w/o the setting enabled) built from:=commit 8c108dccd7f878ad44aaef1f5bfb5622666bd09a (HEAD
,
- add locking and read/write_once calls as needed to provide
synchronization as expected by Linux,
- fix some typos,
- remove return from void functions,
- adjust tracing macros.
Sponsored by: The FreeBSD Foundation
PR: 283903 (rtw88 skb leak)
Tested by
Hello Bjoern,
Seems to be working with rtw88:
# sysctl compat.linuxkpi.80211.hw_crypto
compat.linuxkpi.80211.hw_crypto: 1
# ifconfig wlan2
wlan2: flags=8843 metric 0 mtu 1500
options=0
ether 80:91:33:4b:4a:d1
inet 192.168.0.41 netmask 0xff00 broadcast 192.168.0.255
On Tue, 18 Feb 2025, Bjoern A. Zeeb wrote:
Hi,
anyone with rtw88 or especially rtw89 around to test this as well?
The change is in stable/14 now as well.
Thanks
Bjoern
with [1] I added HW_CRYPTO support to the build for all LinuxKPI based
drivers. This is a pre-condition to make HT/VHT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #38 from Bjoern A. Zeeb ---
(In reply to oleg.nauman from comment #37)
Super!
And thanks to you too for all the debugging and testing also in private!
--
You are receiving this mail because:
You are on the CC list for the bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #37 from oleg.nau...@gmail.com ---
(In reply to Bjoern A. Zeeb from comment #35)
Hello Bjoern,
I can confirm that it helps, thank you
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Bjoern A. Zeeb changed:
What|Removed |Added
Flags||mfc-stable14?
--
You are receivi
locking and read/write_once calls as needed to provide
synchronization as expected by Linux,
- fix some typos,
- remove return from void functions,
- adjust tracing macros.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 283903 (rtw88 skb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Bjoern A. Zeeb changed:
What|Removed |Added
Status|Open|In Progress
--- Comment #35 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #34 from Guillaume Outters ---
(In reply to Guillaume Outters from comment #33)
I had review D48723 patched too.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #33 from Guillaume Outters ---
(In reply to Bjoern A. Zeeb from comment #32)
IT WORKS!
Thank you very much for having taken the time to review the whole code, putting
the missing spin_locks where necessary. It reminds me those
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #32 from Bjoern A. Zeeb ---
Completely untested bu compiling on some kernels:
https://reviews.freebsd.org/D49101
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #31 from Bjoern A. Zeeb ---
I am preparing a patch for you to try. Just waiting for builds to finish.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #30 from Guillaume Outters ---
To reproduce:
it seems that my manual traces + sysctl compat.linuxkpi.skb.debug=0x10 +
visiting Ars Technica
do a wonderful job stressing the c2h_queue and mess after 2 mn of uptime.
Do all the pr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #29 from Guillaume Outters ---
More manual traces, with:
A. In lkpi_80211_txq_tx_one, after dev_alloc_skb()
B. In __skb_queue_tail(), just after the call to __skb_queue_before(), with a
filter to only trace c2h_queue:
print th
With compat.linuxkpi.80211.hw_crypto=1 things seem to work okay so far.
I didn't notice any change in performance.
Since switching to iwlwifi things have been okay for down traffic and
minor up traffic. However if I scp a large file to another machine
then it tends to stall at times. Ping times
returned to the stock 14.1-RELEASE kernel (my
/boot/kernel/kernel was dated 2024-05-31).
> and if not if you want to apply the rtw88 parts
Are we speaking of review D48723 (dev_kfree_skb_any in rtw_pci_tx_write)? If
yes, sadly it doesn't resolve nor mitigates the problem.
Now I t
On Wed, 19 Feb 2025, ltning-freebsd-wirel...@anduin.net wrote:
Hi,
All good on my Framework 13:
iwlwifi0@pci0:170:0:0:class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086
device=0x2725 subvendor=0x8086 subdevice=0x0020
No obvious differences from before. I have a feeling it might be a tad fas
On Wed, 19 Feb 2025, Nuno Teixeira wrote:
(lots of) iwlwifi0: _lkpi_iv_key_set: CIPHER SUITE 0xfac02 not supported
You are using TKIP. As stated that is currently unsupported.
Any reason you still use TKIP?
Rooter has default to PKIP/AES. I've changed it to AES (only).
Connection OK.
compiled in now it is disabled behind a tunable until
there is sufficient feedback for iwlwifi, rtw88 and rtw89 that it works.
Once that happens I'll flip the default for the tunable at least to on
and eventually remove it alltogether and we can move to the next steps
of testing which is hope
>
> >
> > (lots of) iwlwifi0: _lkpi_iv_key_set: CIPHER SUITE 0xfac02 not supported
>
> You are using TKIP. As stated that is currently unsupported.
> Any reason you still use TKIP?
Rooter has default to PKIP/AES. I've changed it to AES (only).
Connection OK.
% sysctl compat.linuxkpi.80211.hw_c
On 2/19/25 04:05, Bjoern A. Zeeb wrote:
Hello.
You don't expect this to work on 14.2, do you?
How would this work on 14.2 if it was just committed to main?
I'll merge it to stable/14.
Sorry I was not clear.
Whay I meant was: is this patch supposed to work on 14.2 after I
cherry-pick it (
d in the commit message I saw one specific panic in the
past which I no longer can reproduce. I am sure there's some other edge
cases on more devices so I need your help to test.
While the code is compiled in now it is disabled behind a tunable until
there is sufficient feedback for iwlwifi,
On Tue, 18 Feb 2025, Andrea Venturoli wrote:
On 2/18/25 05:01, Bjoern A. Zeeb wrote:
Hi,
with [1] I added HW_CRYPTO support to the build for all LinuxKPI based
drivers. This is a pre-condition to make HT/VHT work with drivers/fw
which support, e.g., A-MPDU offloading -- basically almost every
On Tue, 18 Feb 2025, Nuno Teixeira wrote:
wlan0: Ethernet address: 6c:6a:77:df:09:21
re0: link state changed to UP
lo0: link state changed to UP
wlan0: link state changed to UP
iwlwifi0: _lkpi_iv_key_set: CIPHER SUITE 0xfac02 not supported
wlan0: link state changed to DOWN
wlan0: link state chan
On Tue, 18 Feb 2025, Nuno Teixeira wrote:
Same board here.
iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086
device=0x51f1 subvendor=0x8086 subdevice=0x0090
vendor = 'Intel Corporation'
device = 'Raptor Lake PCH CNVi WiFi'
class = network
After com
day, the LinuxKPI parts) if you want to apply the rtw88 parts.
It doesn't solve things but I wonder if it would "behave better".
As for the other parts, not forgotten but my urgencies are currently elsewhere
for a few more days. But given I'll have to go back to rtw88 and rtw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #26 from Guillaume Outters ---
(I have not progressed; however now that my laptop is my main machine, the bug
starts to be really annoying, with 1 or 2 reboots required by day as you may
have Oleg)
And I've attempted reorganizi
(...)
> iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086
>>> device=0x51f1 subvendor=0x8086 subdevice=0x0090
>>>vendor = 'Intel Corporation'
>>>device = 'Raptor Lake PCH CNVi WiFi'
>>>class = network
>>>
>>
My wifi card is: Intel(R) Wi-Fi 6 AX201 160M
(...)
At main-n275504-11db70b6057e
==> Without compat.linuxkpi.80211.hw_crypto=1 everything OK:
% ifconfig wlan0 scan
SSID/MESH ID BSSID CHAN RATES:N
INT CAPS
Vodafone-24EF21 9c:b2:e8:fd:6c:8c8 54M -96:-96
100 EPS RSN WME BSSLOAD HT
Hello,
Same board here.
iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x01 hdr=0x00 vendor=0x8086
> device=0x51f1 subvendor=0x8086 subdevice=0x0090
>vendor = 'Intel Corporation'
>device = 'Raptor Lake PCH CNVi WiFi'
>class = network
>
After compat.linuxkpi.80211.hw_crypto=1
On 2/18/25 05:01, Bjoern A. Zeeb wrote:
Hi,
with [1] I added HW_CRYPTO support to the build for all LinuxKPI based
drivers. This is a pre-condition to make HT/VHT work with drivers/fw
which support, e.g., A-MPDU offloading -- basically almost everything
modern.
I will very likely MFC it at the
t message I saw one specific panic in the
past which I no longer can reproduce. I am sure there's some other edge
cases on more devices so I need your help to test.
While the code is compiled in now it is disabled behind a tunable until
there is sufficient feedback for iwlwifi, rtw88 and
o I need your help to test.
>
> While the code is compiled in now it is disabled behind a tunable until
> there is sufficient feedback for iwlwifi, rtw88 and rtw89 that it works.
> Once that happens I'll flip the default for the tunable at least to on
> and eventually remove it alltog
nic in the
past which I no longer can reproduce. I am sure there's some other edge
cases on more devices so I need your help to test.
While the code is compiled in now it is disabled behind a tunable until
there is sufficient feedback for iwlwifi, rtw88 and rtw89 that it works.
Once that h
Hi,
I just pushed a big bunch of MFCs which brings the updated drivers from
freebsd main (HEAD/CURRENT) [done in Nov? 2024] to stable/14.
I had initially waited until 14.2 was out but then also now until I had
the moment.
Please test them and follow-up in case you notice some new oddities.
Lot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283142
Bjoern A. Zeeb changed:
What|Removed |Added
Flags||needs_errata?
--- Comment #27 fro
Author: Bjoern A. Zeeb
AuthorDate: 2024-12-20 14:23:50 +
Commit: Bjoern A. Zeeb
CommitDate: 2025-02-06 20:52:42 +
LinuxKPI 802.11 / rtw88: make packets flow again
In 886653492945f we added checks for packets to only go out if the
station is known to the firmware (amongst
Author: Bjoern A. Zeeb
AuthorDate: 2024-12-20 14:23:50 +
Commit: Bjoern A. Zeeb
CommitDate: 2025-02-06 20:49:51 +
LinuxKPI 802.11 / rtw88: make packets flow again
In 886653492945f we added checks for packets to only go out if the
station is known to the firmware (amongst
-
Notes
--- (1) Test procedure
vms() { vmstat -m | egrep -e '(Use|lkpi|mbuf)' ; }
dt() { sudo dtrace -s rtw88-skb.d | egrep -v
'kernel.0x|fork_exit|taskqueue_thread_loop|softclock_thread' ; }
for p in "rx b:/tmp/1 /tmp/" "tx /tmp/1 b:/tm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #24 from Guillaume Outters ---
Created attachment 257183
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257183&action=edit
Dtrace and vmstat after a 10 MiB send
--
You are receiving this mail because:
You are on the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #23 from Guillaume Outters ---
Created attachment 257182
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257182&action=edit
Dtrace and vmstat after a 10 MiB receive
--
You are receiving this mail because:
You are on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #22 from Bjoern A. Zeeb ---
(In reply to Guillaume Outters from comment #21)
The 16M ring + 1rsvd page would match as a start.
Thanks a lot for the detailed answer.
I just realized why we do see the 4K increases but I did not
and as
a result got 1 or 2 hours without "skb alloc failed").
> Did you also instrument the RX path?
> Are your SCPs pushing or pulling data? as in do you copy a file off from the
> rtw88 device or do you copy a file to the rtw88 device?
> But also 170 bytes is really not m
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #20 from oleg.nau...@gmail.com ---
(In reply to Bjoern A. Zeeb from comment #18)
I have applied patch from https://reviews.freebsd.org/D48723 with
compat.linuxkpi.rtw88_debug_mask=0x0800 set but kernel does not produce any
skb free call (there are more in the driver I fixed in
the past):
I wonder if we are leaking somewhere else inside rtw88 slowly; we should go and
see where skb_allocations are matching a page (like the rsvd page or similar).
It seems it's a small number (0.023676%).
[and while I am writ
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #18 from Bjoern A. Zeeb ---
Short into the dark II:
The patch to apply is here (you can use arc or download it from the right side)
https://reviews.freebsd.org/D48723
set
compat.linuxkpi.rtw88_debug_mask=0x0800
in loader
nd^M
rtw881: pci bus timeout, check dma status^M
rtw881: pci bus timeout, check dma status^M
rtw881: pci bus timeout, check dma status^M
rtw881: pci bus timeout, check dma status^M
...
rtw881 is:
[109.713728] rtw881: port 0x3000-0x30ff mem 0xd010-0xd010
irq 41 at device 0.0 on pci9^M
[109.
instrument the RX path?
Are your SCPs pushing or pulling data? as in do you copy a file off from the
rtw88 device or do you copy a file to the rtw88 device?
BTW. you do not have to patch the kernel for this. Dtrace provides adequate
tracing functionality in this case.
Here's a sample I s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #15 from Guillaume Outters ---
(regarding my question on how to start playing with the kernel and if linux_kpi
was externalizable as a module, I resolved to learn how to compile and start a
full custom kernel, which is a bit ted
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283142
Bjoern A. Zeeb changed:
What|Removed |Added
CC||test.ppk...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #14 from Bjoern A. Zeeb ---
(In reply to oleg.nauman from comment #13)
I'll just put it here given I am a bit short on time the next days to look at
this further.
Oleg commented out the loop dumping the queues in LinuxKPI upon
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #13 from oleg.nau...@gmail.com ---
(In reply to Bjoern A. Zeeb from comment #10)
It caused kernel panic after 1 hour 47 minutes of uptime
Jan 17 08:21:23 kernel: rtw880: ERROR lkpi_80211_txq_tx_one: skb alloc failed
48 + 163,
I only used FreeBSD on preinstalled dedicated servers, or on
VirtualBox guests).
Ideally I'd test it live, with a bit of kldunload / kldload, remaking only in
modules/rtw88 and modules/linuxkpi_wlan.
However, this only works for if_rtw88.ko (ifconfig wlan0 down ; kldunload
if_rtw88.ko ; kl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #11 from oleg.nau...@gmail.com ---
(In reply to Bjoern A. Zeeb from comment #10)
Hello Bjoern,
I will test it tomorrow.
Thank you
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #10 from Bjoern A. Zeeb ---
This is a shot in the dark and a hack but can you two try to apply the changes
from
https://reviews.freebsd.org/D48474
and see if that helps? If it does we can find a proper solution not abusing an
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #9 from Guillaume Outters ---
OK, I was wrong thinking the compiler eating mem induced rtw88 into error:
now I'm convinced that rtw88 ate so much mem that clang hadn't enough anymore.
Twice this week I observed lpk
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #8 from Guillaume Outters ---
Created attachment 256704
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256704&action=edit
vmstat req and mem during scp before / after going rogue
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #7 from Guillaume Outters ---
Whoops, I got a new one!
After an uptime of more than 2 days without any problem, I once again had two
killed processes yesterday evening (while building GHC, the Haskell compiler),
and then this mo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #6 from oleg.nau...@gmail.com ---
Hello,
It would be nice if you provide Bjoern with output
vmstat -m | egrep -E "lkpiskb|Memory"
when it happens again
--
You are receiving this mail because:
You are on the CC list for the b
compat.linuxkpi.skb.mem_limit to 1 too.
In my case they start interleaved with, or sometimes hours after, some:
Dec 31 16:35:26 pasdfric kernel: pid 54454 (clang++), jid 0, uid 1001, was
killed: failed to reclaim memory
But once I started having some "skb alloc failed", the situation degrades for
rtw88,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #4 from oleg.nau...@gmail.com ---
(In reply to Guillaume Outters from comment #3)
Hello,
I can not confirm that "skb allocation failure" happens only when virtual
memory is exhausted
Could you please directly confirm that you a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
--- Comment #3 from Guillaume Outters ---
Here it seems to happen only after memory has been exhausted at least once:
after a reboot there *always* (see (1)) have to happen a bunch of "kernel: pid
xxx (x), jid 0, uid 1001, was killed: f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903
Guillaume Outters changed:
What|Removed |Added
CC||guillaume-freebsd@outters.e
1 - 100 of 200 matches
Mail list logo
