On 6/25/23 13:12, Arnd Bergmann wrote:
> On Sun, Jun 25, 2023, at 18:58, Sardonimous wrote:
>> I have been unable to get DMA to work in the past. So I have been
>> configuring it with PIO=1 (/etc/modprobe,d/b43.conf):
>>
>> options b43 pio=1 qos=0
>>
>
> I think the qos=0 parameter is what causes the WARN_ON(), as that
> causes the use of only one queue, while the warning happens when
> tx function iterates over all the queues and warns that they don't
> exist.
I agree and suggest running with no options. If we need debug, we can turn it on
later.
Larry
On 6/25/23 13:17, Larry Finger wrote:
> On 6/25/23 13:12, Arnd Bergmann wrote:
>> On Sun, Jun 25, 2023, at 18:58, Sardonimous wrote:
>>> I have been unable to get DMA to work in the past. So I have been
>>> configuring it with PIO=1 (/etc/modprobe,d/b43.conf):
>>>
>>> options b43 pio=1 qos=0
>>>
>>
>> I think the qos=0 parameter is what causes the WARN_ON(), as that
>> causes the use of only one queue, while the warning happens when
>> tx function iterates over all the queues and warns that they don't
>> exist.
>
> I agree and suggest running with no options. If we need debug, we can
> turn it on later.
>
> Larry
Sure. Of course, this is what I started out with years ago (2017?) when
I was trying to get this to work.
Now:
Linux version 6.3.9-arch1-1 (linux@archlinux) (gcc (GCC) 13.1.1
20230429, GNU ld (GNU Binutils) 2.40.0) #1 SMP PREEMPT_DYNAMIC Wed, 21
Jun 2023 20:46:20 +0000
This is the sort of loop I get (dmesg | grep b43):
[ 31.979539] b43-pci-bridge 0000:02:00.0: Sonics Silicon Backplane
found on PCI device 0000:02:00.0
[ 35.239389] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
[ 35.275018] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4
[ 35.275046] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision
3, Version 0
[ 66.890631] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 67.437162] b43-phy0 ERROR: DMA RX reset timed out
[ 67.498976] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
register 0F90 to clear
[ 67.707177] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 391.127300] b43-phy0 ERROR: DMA RX reset timed out
[ 391.360514] b43-phy0 ERROR: DMA TX reset timed out
[ 391.382127] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
register 0F90 to clear
[ 391.590659] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 709.123840] b43-phy0 ERROR: DMA RX reset timed out
[ 709.357235] b43-phy0 ERROR: DMA TX reset timed out
[ 709.378623] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
register 0F90 to clear
[ 709.573851] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
On 6/25/23 16:11, Sardonimous wrote:
> On 6/25/23 13:17, Larry Finger wrote:
>
>> On 6/25/23 13:12, Arnd Bergmann wrote:
>>> On Sun, Jun 25, 2023, at 18:58, Sardonimous wrote:
>>>> I have been unable to get DMA to work in the past. So I have been
>>>> configuring it with PIO=1 (/etc/modprobe,d/b43.conf):
>>>>
>>>> options b43 pio=1 qos=0
>>>>
>>>
>>> I think the qos=0 parameter is what causes the WARN_ON(), as that
>>> causes the use of only one queue, while the warning happens when
>>> tx function iterates over all the queues and warns that they don't
>>> exist.
>>
>> I agree and suggest running with no options. If we need debug, we can turn it
>> on later.
>>
>> Larry
>
> Sure. Of course, this is what I started out with years ago (2017?) when I was
> trying to get this to work.
>
> Now:
> Linux version 6.3.9-arch1-1 (linux@archlinux) (gcc (GCC) 13.1.1 20230429, GNU ld
> (GNU Binutils) 2.40.0) #1 SMP PREEMPT_DYNAMIC Wed, 21 Jun 2023 20:46:20 +0000
>
> This is the sort of loop I get (dmesg | grep b43):
>
> [ 31.979539] b43-pci-bridge 0000:02:00.0: Sonics Silicon Backplane found on
> PCI device 0000:02:00.0
> [ 35.239389] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
> [ 35.275018] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4
> [ 35.275046] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision 3, Version 0
> [ 66.890631] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
> [ 67.437162] b43-phy0 ERROR: DMA RX reset timed out
> [ 67.498976] b43 ssb0:0: Timeout waiting for bitmask 01800000 on register 0F90
> to clear
> [ 67.707177] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
> [ 391.127300] b43-phy0 ERROR: DMA RX reset timed out
> [ 391.360514] b43-phy0 ERROR: DMA TX reset timed out
> [ 391.382127] b43 ssb0:0: Timeout waiting for bitmask 01800000 on register 0F90
> to clear
> [ 391.590659] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
> [ 709.123840] b43-phy0 ERROR: DMA RX reset timed out
> [ 709.357235] b43-phy0 ERROR: DMA TX reset timed out
> [ 709.378623] b43 ssb0:0: Timeout waiting for bitmask 01800000 on register 0F90
> to clear
> [ 709.573851] b43-phy0: Loading firmware version 784.2 (2012-08-15 21:35:19)
Sardonimous,
Did it ever work with DMA. or was PIO the only way to get it to work?
If you add in only the pio=1 option without qos, will it work?
If I were to send you some test patches, could you create a kernel with them
applied?
Larry
On 6/25/23 18:05, Larry Finger wrote:
> On 6/25/23 16:11, Sardonimous wrote:
>> On 6/25/23 13:17, Larry Finger wrote:
>>
>>> On 6/25/23 13:12, Arnd Bergmann wrote:
>>>> On Sun, Jun 25, 2023, at 18:58, Sardonimous wrote:
>>>>> I have been unable to get DMA to work in the past. So I have been
>>>>> configuring it with PIO=1 (/etc/modprobe,d/b43.conf):
>>>>>
>>>>> options b43 pio=1 qos=0
>>>>>
>>>>
>>>> I think the qos=0 parameter is what causes the WARN_ON(), as that
>>>> causes the use of only one queue, while the warning happens when
>>>> tx function iterates over all the queues and warns that they don't
>>>> exist.
>>>
>>> I agree and suggest running with no options. If we need debug, we
>>> can turn it on later.
>>>
>>> Larry
>>
>> Sure. Of course, this is what I started out with years ago (2017?)
>> when I was trying to get this to work.
>>
>> Now:
>> Linux version 6.3.9-arch1-1 (linux@archlinux) (gcc (GCC) 13.1.1
>> 20230429, GNU ld (GNU Binutils) 2.40.0) #1 SMP PREEMPT_DYNAMIC Wed,
>> 21 Jun 2023 20:46:20 +0000
>>
>> This is the sort of loop I get (dmesg | grep b43):
>>
>> [ 31.979539] b43-pci-bridge 0000:02:00.0: Sonics Silicon Backplane
>> found on PCI device 0000:02:00.0
>> [ 35.239389] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
>> [ 35.275018] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4
>> [ 35.275046] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056,
>> Revision 3, Version 0
>> [ 66.890631] b43-phy0: Loading firmware version 784.2 (2012-08-15
>> 21:35:19)
>> [ 67.437162] b43-phy0 ERROR: DMA RX reset timed out
>> [ 67.498976] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
>> register 0F90 to clear
>> [ 67.707177] b43-phy0: Loading firmware version 784.2 (2012-08-15
>> 21:35:19)
>> [ 391.127300] b43-phy0 ERROR: DMA RX reset timed out
>> [ 391.360514] b43-phy0 ERROR: DMA TX reset timed out
>> [ 391.382127] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
>> register 0F90 to clear
>> [ 391.590659] b43-phy0: Loading firmware version 784.2 (2012-08-15
>> 21:35:19)
>> [ 709.123840] b43-phy0 ERROR: DMA RX reset timed out
>> [ 709.357235] b43-phy0 ERROR: DMA TX reset timed out
>> [ 709.378623] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
>> register 0F90 to clear
>> [ 709.573851] b43-phy0: Loading firmware version 784.2 (2012-08-15
>> 21:35:19)
>
> Sardonimous,
>
> Did it ever work with DMA. or was PIO the only way to get it to work?
No, I never got it to work without specifying PIO=1.
> If you add in only the pio=1 option without qos, will it work?
In this case, authentication to the router fails.
[ 31.021510] b43-pci-bridge 0000:02:00.0: Sonics Silicon Backplane
found on PCI device 0000:02:00.0
[ 33.889890] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
[ 33.925016] b43-phy0: Found PHY: Analog 8, Type 4 (N), Revision 4
[ 33.925053] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2056, Revision
3, Version 0
[ 63.863977] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 64.170661] b43-phy0 warning: Forced PIO by use_pio module parameter.
This should not be needed and will result in lower performance.
[ 64.550635] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 64.847342] b43-phy0 warning: Forced PIO by use_pio module parameter.
This should not be needed and will result in lower performance.
[ 90.247286] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 90.514031] b43-phy0 warning: Forced PIO by use_pio module parameter.
This should not be needed and will result in lower performance.
[ 91.263462] wlan0: authenticate with 0c:80:63:26:16:b5
[ 91.551389] wlan0: send auth to 0c:80:63:26:16:b5 (try 1/3)
[ 91.551916] wlan0: authenticated
[ 91.553776] wlan0: associate with 0c:80:63:26:16:b5 (try 1/3)
[ 91.554656] wlan0: RX AssocResp from 0c:80:63:26:16:b5 (capab=0x11
status=0 aid=9)
[ 91.554883] wlan0: associated
[ 99.619556] wlan0: deauthenticated from 0c:80:63:26:16:b5 (Reason:
15=4WAY_HANDSHAKE_TIMEOUT)
[ 100.348068] wlan0: authenticate with 0c:80:63:26:16:b4
[ 100.640896] wlan0: send auth to 0c:80:63:26:16:b4 (try 1/3)
[ 100.647930] wlan0: authenticated
[ 100.653778] wlan0: associate with 0c:80:63:26:16:b4 (try 1/3)
[ 100.654653] wlan0: RX AssocResp from 0c:80:63:26:16:b4 (capab=0x11
status=0 aid=9)
[ 100.654884] wlan0: associated
[ 108.717245] wlan0: deauthenticated from 0c:80:63:26:16:b4 (Reason:
15=4WAY_HANDSHAKE_TIMEOUT)
[ 109.267996] wlan0: authenticate with 0c:80:63:26:16:b6
[ 109.767538] wlan0: send auth to 0c:80:63:26:16:b6 (try 1/3)
[ 109.769105] wlan0: authenticated
[ 109.773778] wlan0: associate with 0c:80:63:26:16:b6 (try 1/3)
[ 109.776774] wlan0: RX AssocResp from 0c:80:63:26:16:b6 (capab=0x431
status=0 aid=3)
[ 109.777254] wlan0: associated
[ 116.001372] wlan0: deauthenticating from 0c:80:63:26:16:b6 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 126.612857] wlan0: authenticate with 0c:80:63:26:16:b5
[ 127.234092] wlan0: send auth to 0c:80:63:26:16:b5 (try 1/3)
[ 127.234734] wlan0: authenticated
[ 127.237108] wlan0: associate with 0c:80:63:26:16:b5 (try 1/3)
[ 127.238173] wlan0: RX AssocResp from 0c:80:63:26:16:b5 (capab=0x11
status=0 aid=9)
[ 127.238410] wlan0: associated
[ 136.279232] wlan0: deauthenticated from 0c:80:63:26:16:b5 (Reason:
15=4WAY_HANDSHAKE_TIMEOUT)
[ 136.991245] wlan0: authenticate with 0c:80:63:26:16:b4
[ 137.254104] wlan0: send auth to 0c:80:63:26:16:b4 (try 1/3)
[ 137.254645] wlan0: authenticated
[ 137.260507] wlan0: associate with 0c:80:63:26:16:b4 (try 1/3)
[ 137.261447] wlan0: RX AssocResp from 0c:80:63:26:16:b4 (capab=0x11
status=0 aid=9)
[ 137.261699] wlan0: associated
[ 141.001670] wlan0: deauthenticating from 0c:80:63:26:16:b4 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 141.081565] wlan0: authenticate with 0c:80:63:26:16:b4
[ 141.117429] wlan0: send auth to 0c:80:63:26:16:b4 (try 1/3)
[ 141.117979] wlan0: authenticated
[ 141.123927] wlan0: associate with 0c:80:63:26:16:b4 (try 1/3)
[ 141.124662] wlan0: RX AssocResp from 0c:80:63:26:16:b4 (capab=0x11
status=0 aid=9)
[ 141.124895] wlan0: associated
[ 149.240176] wlan0: deauthenticated from 0c:80:63:26:16:b4 (Reason:
15=4WAY_HANDSHAKE_TIMEOUT)
[ 166.273957] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 166.577378] b43-phy0 warning: Forced PIO by use_pio module parameter.
This should not be needed and will result in lower performance.
[ 177.507291] b43-phy0: Loading firmware version 784.2 (2012-08-15
21:35:19)
[ 177.780745] b43-phy0 warning: Forced PIO by use_pio module parameter.
This should not be needed and will result in lower performance.If I were
to send you some test patches, could you create a kernel with them applied?
Doubtful.
> Larry
On 6/26/23 07:44, Sardonimous wrote:
> If I were to send you some test patches, could you create a kernel with them
> applied?
>
> Doubtful.
Sardonimous,
OK, that essentially eliminates getting DMA to work. The cost of a MacBookPro7
is too much for me to acquire one to debug that issue.
On my PowerBook G4, I also got the failure to connect, thus I should be able to
fix that problem, but getting a new kernel with the fix onto your machine will
not be easy.
Is it possible to ssh into your machine, or to use TeamViewer? Those questions
do not need an answer now, but think about them.
Larry
On 6/26/23 10:21 AM, Larry Finger wrote:
> On 6/26/23 07:44, Sardonimous wrote:
>> If I were to send you some test patches, could you create a kernel
>> with them applied?
>>
>> Doubtful.
>
> Sardonimous,
>
> OK, that essentially eliminates getting DMA to work. The cost of a
> MacBookPro7 is too much for me to acquire one to debug that issue.
>
> On my PowerBook G4, I also got the failure to connect, thus I should
> be able to fix that problem, but getting a new kernel with the fix
> onto your machine will not be easy.
It might be possible to follow the arch instructions for patching the kernel
https://wiki.archlinux.org/title/Kernel/Arch_build_system
It takes about a day to rebuild the kernel following this procedure.
> Is it possible to ssh into your machine, or to use TeamViewer? Those
> questions do not need an answer now, but think about them.
This is complicated by being in a CGNAT environment. I usually do this
via tailscale. Will have to think about it.
> Larry
Should pio=1 qos=0 cause the problems that it does? It if is no longer
a supported configuration, perhaps it should fail more gracefully.
On 6/26/23 16:33, Sardonimous wrote:
>
> On 6/26/23 10:21 AM, Larry Finger wrote:
>> On 6/26/23 07:44, Sardonimous wrote:
>>> If I were to send you some test patches, could you create a kernel with them
>>> applied?
>>>
>>> Doubtful.
>>
>> Sardonimous,
>>
>> OK, that essentially eliminates getting DMA to work. The cost of a
>> MacBookPro7 is too much for me to acquire one to debug that issue.
>>
>> On my PowerBook G4, I also got the failure to connect, thus I should be able
>> to fix that problem, but getting a new kernel with the fix onto your machine
>> will not be easy.
>
> It might be possible to follow the arch instructions for patching the kernel
>
> https://wiki.archlinux.org/title/Kernel/Arch_build_system
>
> It takes about a day to rebuild the kernel following this procedure.
>
>> Is it possible to ssh into your machine, or to use TeamViewer? Those questions
>> do not need an answer now, but think about them.
>
> This is complicated by being in a CGNAT environment. I usually do this via
> tailscale. Will have to think about it.
>
>> Larry
>
> Should pio=1 qos=0 cause the problems that it does? It if is no longer a
> supported configuration, perhaps it should fail more gracefully.
Setting qos=0 will generate a harmless warning, but the network still works.
Using pio=1 should still be supported.
I am bisecting the source. It will take a while as I still have 13 kernels to
build and my PowerBook G4 takes about 6 hours per build - it is a lot slower
than your computer. At this point, I know that kernel v6.1.0 works, and that
v6.2.0-rc4 fails.
If you can find a 6.1 kernel, it should work for you. Once I know the fix, we
can explore having you patch and rebuild your 6.3.X kernel.
Larry
On 6/26/23 16:33, Sardonimous wrote:
>
> On 6/26/23 10:21 AM, Larry Finger wrote:
>> On 6/26/23 07:44, Sardonimous wrote:
>>> If I were to send you some test patches, could you create a kernel with them
>>> applied?
>>>
>>> Doubtful.
>>
>> Sardonimous,
>>
>> OK, that essentially eliminates getting DMA to work. The cost of a
>> MacBookPro7 is too much for me to acquire one to debug that issue.
>>
>> On my PowerBook G4, I also got the failure to connect, thus I should be able
>> to fix that problem, but getting a new kernel with the fix onto your machine
>> will not be easy.
>
> It might be possible to follow the arch instructions for patching the kernel
>
> https://wiki.archlinux.org/title/Kernel/Arch_build_system
>
> It takes about a day to rebuild the kernel following this procedure.
>
>> Is it possible to ssh into your machine, or to use TeamViewer? Those questions
>> do not need an answer now, but think about them.
>
> This is complicated by being in a CGNAT environment. I usually do this via
> tailscale. Will have to think about it.
>
>> Larry
>
> Should pio=1 qos=0 cause the problems that it does? It if is no longer a
> supported configuration, perhaps it should fail more gracefully.
Sardonimous,
Sorry that it took so long to get back to you.
For my ppc32, there is no regression. It took a while to learn the pio=1 and
qos=0 are BOTH needed. That I do not understand, but with both set, the device
works with kernel 6.4 and all earlier kernels that I tried. Fortunately, I did
not need to do the entire bisection.
I am working on eliminating the warning that appears with qos=0, but it does not
inhibit operations.
@Bagas Sanjaya: Please mark this "regression" as invalid.
Larry
On 7/3/23 12:35 PM, Larry Finger wrote:
> Sorry that it took so long to get back to you.
>
> For my ppc32, there is no regression. It took a while to learn the
> pio=1 and qos=0 are BOTH needed. That I do not understand, but with
> both set, the device works with kernel 6.4 and all earlier kernels
> that I tried. Fortunately, I did not need to do the entire bisection.
>
> I am working on eliminating the warning that appears with qos=0, but
> it does not inhibit operations.
>
> @Bagas Sanjaya: Please mark this "regression" as invalid.
>
> Larry
>
I appreciate the time you've spent on this. I did try 6.4 again (6.4.1
actually) and wlan0 did eventually come active. When I tried this
before, I probably got freaked by the number of WARNINGs when it wasn't
connecting, but perhaps it was failing for some other reason. I didn't
realize they were only warnings.
$ uptime
15:10:52 up 9 min, 3 users, load average: 0.11, 0.92, 0.85
$ journalctl --boot | grep "WARNING.*__ieee80211_stop_queue+0xcc/0xe0"
| wc -l
111
Regards.
On 03.07.23 22:13, Sardonimous wrote:
> On 7/3/23 12:35 PM, Larry Finger wrote:
>> Sorry that it took so long to get back to you.
>>
>> For my ppc32, there is no regression. It took a while to learn the
>> pio=1 and qos=0 are BOTH needed. That I do not understand, but with
>> both set, the device works with kernel 6.4 and all earlier kernels
>> that I tried. Fortunately, I did not need to do the entire bisection.
>>
>> I am working on eliminating the warning that appears with qos=0, but
>> it does not inhibit operations.
>>
>> @Bagas Sanjaya: Please mark this "regression" as invalid.
>>
>> Larry
>>
> I appreciate the time you've spent on this.
Yeah, thx from my side, too.
#regzbot invalid: wasn't a regression after all
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.