* Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
@ 2023-06-24 1:44 Bagas Sanjaya
2023-06-24 8:50 ` Michael Büsch
2023-06-24 21:32 ` Fwd: " Arnd Bergmann
0 siblings, 2 replies; 21+ messages in thread
From: Bagas Sanjaya @ 2023-06-24 1:44 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Linux Networking
Cc: Arnd Bergmann, Michael Büsch, kernel test robot,
Simon Horman, Larry Finger, Kalle Valo, sardonimous
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> After upgrading to linux 6.3.8-arch1-1 from 6.3.6-arch1-1, b43 broadcom wireless driver fails. downgrading back to 6.3.6-arch1-1 resolves.
>
> Jun 16 20:56:37 askasleikir kernel: Hardware name: Apple Inc. MacBookPro7,1/Mac-F222BEC8, BIOS MBP71.88Z.0039.B15.1702241313 02/24/17
> Jun 16 20:56:37 askasleikir kernel: Workqueue: phy0 b43_tx_work [b43]
> Jun 16 20:56:37 askasleikir kernel: RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
> Jun 16 20:56:37 askasleikir kernel: Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 5b eb 00 00 65 ff 0d 0c dd b5 3e 0f 85 55 ff ff ff e8 b9 f4 12 de e9 4b ff>
> Jun 16 20:56:37 askasleikir kernel: RSP: 0000:ffffc36b0013bdb8 EFLAGS: 00010097
> Jun 16 20:56:37 askasleikir kernel: RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
> Jun 16 20:56:37 askasleikir kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff9f85d1c108e0
> Jun 16 20:56:37 askasleikir kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9f85c0819674
> Jun 16 20:56:37 askasleikir kernel: R10: 0000000000000005 R11: 0000000000000181 R12: ffff9f85d1c108e0
> Jun 16 20:56:37 askasleikir kernel: R13: 0000000000000000 R14: ffff9f85d1c12238 R15: ffff9f85d1c12090
> Jun 16 20:56:37 askasleikir kernel: FS: 0000000000000000(0000) GS:ffff9f85fbe00000(0000) knlGS:0000000000000000
> Jun 16 20:56:37 askasleikir kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 16 20:56:37 askasleikir kernel: CR2: 000055b33bbd5d70 CR3: 0000000022620000 CR4: 00000000000406f0
> Jun 16 20:56:37 askasleikir kernel: Call Trace:
> Jun 16 20:56:37 askasleikir kernel: <TASK>
> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
> Jun 16 20:56:37 askasleikir kernel: ? __warn+0x81/0x130
> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
> Jun 16 20:56:37 askasleikir kernel: ? report_bug+0x171/0x1a0
> Jun 16 20:56:37 askasleikir kernel: ? handle_bug+0x3c/0x80
> Jun 16 20:56:37 askasleikir kernel: ? exc_invalid_op+0x17/0x70
> Jun 16 20:56:37 askasleikir kernel: ? asm_exc_invalid_op+0x1a/0x20
> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
> Jun 16 20:56:37 askasleikir kernel: ieee80211_stop_queue+0x36/0x50 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
> Jun 16 20:56:37 askasleikir kernel: b43_pio_tx+0x373/0x390 [b43 0f6039cbd530df6f28ebbb52898f2f67b84598dd]
> Jun 16 20:56:37 askasleikir kernel: ? __schedule+0x44b/0x1400
> Jun 16 20:56:37 askasleikir kernel: b43_tx_work+0x57/0x130 [b43 0f6039cbd530df6f28ebbb52898f2f67b84598dd]
> Jun 16 20:56:37 askasleikir kernel: process_one_work+0x1c7/0x3d0
> Jun 16 20:56:37 askasleikir kernel: worker_thread+0x51/0x390
> Jun 16 20:56:37 askasleikir kernel: ? __pfx_worker_thread+0x10/0x10
> Jun 16 20:56:37 askasleikir kernel: kthread+0xde/0x110
> Jun 16 20:56:37 askasleikir kernel: ? __pfx_kthread+0x10/0x10
> Jun 16 20:56:37 askasleikir kernel: ret_from_fork+0x2c/0x50
> Jun 16 20:56:37 askasleikir kernel: </TASK>
> Jun 16 20:56:37 askasleikir kernel: ---[ end trace 0000000000000000 ]---
>
> I suspect change introduced when addressing a compiler warning cased the error.
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20230516183442.536589-1-arnd%40kernel.org/
>
> The is arch linux and they referred me here.
See Bugzilla for the full thread.
Unfortunately, the reporter can't perform bisection to confirm that
backport of 212457ccbd60db triggers this regression.
Anyway, I'm adding it to regzbot to be sure that it doesn't fall
through cracks unnoticed:
#regzbot introduced: 212457ccbd60db https://bugzilla.kernel.org/show_bug.cgi?id=217582
#regzbot title: fixing incorrect __packed annotation for Clang causes b43 driver fail to start
Thanks.
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-24 1:44 Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails Bagas Sanjaya
@ 2023-06-24 8:50 ` Michael Büsch
2023-06-24 9:29 ` Arnd Bergmann
2023-06-24 21:32 ` Fwd: " Arnd Bergmann
1 sibling, 1 reply; 21+ messages in thread
From: Michael Büsch @ 2023-06-24 8:50 UTC (permalink / raw)
To: Bagas Sanjaya
Cc: Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Linux Networking, Arnd Bergmann, kernel test robot, Simon Horman,
Larry Finger, Kalle Valo, sardonimous
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
On Sat, 24 Jun 2023 08:44:15 +0700
Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> > I suspect change introduced when addressing a compiler warning
> > cased the error.
> >
> > https://patchwork.kernel.org/project/linux-wireless/patch/20230516183442.536589-1-arnd%40kernel.org/
I doubt it.
This patch affects the device initialization code. But the crash is in
the transmit path.
Can you please double check by manually reverting the patch?
--
Michael Büsch
https://bues.ch/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-24 8:50 ` Michael Büsch
@ 2023-06-24 9:29 ` Arnd Bergmann
2023-06-24 14:00 ` Linux regression tracking (Thorsten Leemhuis)
0 siblings, 1 reply; 21+ messages in thread
From: Arnd Bergmann @ 2023-06-24 9:29 UTC (permalink / raw)
To: Michael Büsch, Bagas Sanjaya
Cc: Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev, kernel test robot, Simon Horman, Larry Finger,
Kalle Valo, sardonimous
On Sat, Jun 24, 2023, at 10:50, Michael Büsch wrote:
> On Sat, 24 Jun 2023 08:44:15 +0700
> Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>> > I suspect change introduced when addressing a compiler warning
>> > cased the error.
>> >
>> > https://patchwork.kernel.org/project/linux-wireless/patch/20230516183442.536589-1-arnd%40kernel.org/
>
>
> I doubt it.
> This patch affects the device initialization code. But the crash is in
> the transmit path.
> Can you please double check by manually reverting the patch?
I'm travelling at the moment and can't easily check it, but I would
expect that my patch has no effect on the generated object code at
all. If the compiler output is different with and without my patch,
it's probably wrong. I double-checked the structure layout in
https://godbolt.org, this did not produce any changes, as size,
alignement and offsets of the members are all the same.
Arnd
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-24 9:29 ` Arnd Bergmann
@ 2023-06-24 14:00 ` Linux regression tracking (Thorsten Leemhuis)
2023-06-24 16:22 ` Larry Finger
0 siblings, 1 reply; 21+ messages in thread
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-06-24 14:00 UTC (permalink / raw)
To: Arnd Bergmann, Michael Büsch, Bagas Sanjaya
Cc: Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev, kernel test robot, Simon Horman, Larry Finger,
Kalle Valo, sardonimous
On 24.06.23 11:29, Arnd Bergmann wrote:
> On Sat, Jun 24, 2023, at 10:50, Michael Büsch wrote:
>> On Sat, 24 Jun 2023 08:44:15 +0700
>> Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>> I suspect change introduced when addressing a compiler warning
>>>> cased the error.
>>>>
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20230516183442.536589-1-arnd%40kernel.org/
>>
>> I doubt it.
>> This patch affects the device initialization code. But the crash is in
>> the transmit path.
>> Can you please double check by manually reverting the patch?
>
> I'm travelling at the moment and can't easily check it, but I would
> expect that my patch has no effect on the generated object code [...]
Michael, Arnd, thx for the replies. To you and everyone else that looked
into this: sorry for the trouble this caused.
The reporter's guess was wrong, as the reporter meanwhile confirmed in
the bugzilla ticket that the problem started to happen earlier.
Bagas, please be a bit more careful and don't blame a specific commit
unless it's was found by bisection, a revert through a lucky guess, a
statement from a developer, or something like that. In cases like this
it would have been better to sent the developers of said commit a quick
mail along the lines of "could you imagine that this change could lead
to the problem the reporter described". But even that might be too much
in a case like this, as too many of such false alarms and inquiries will
make developers start hating or ignoring regression tracking in general
or mails from you or me – and that is something that must be avoided, as
without help from developers regression tracking becomes a lot harder or
impossible.
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
If I did something stupid, please tell me, as explained on that page.
P.S.: Updating regzbot status, while at it:
#regzbot introduced: v6.1..v6.2
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-24 14:00 ` Linux regression tracking (Thorsten Leemhuis)
@ 2023-06-24 16:22 ` Larry Finger
0 siblings, 0 replies; 21+ messages in thread
From: Larry Finger @ 2023-06-24 16:22 UTC (permalink / raw)
To: Linux regressions mailing list, Arnd Bergmann,
Michael Büsch, Bagas Sanjaya
Cc: Linux Kernel Mailing List, Linux Wireless, Netdev,
kernel test robot, Simon Horman, Kalle Valo, sardonimous
On 6/24/23 09:00, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 24.06.23 11:29, Arnd Bergmann wrote:
>> On Sat, Jun 24, 2023, at 10:50, Michael Büsch wrote:
>>> On Sat, 24 Jun 2023 08:44:15 +0700
>>> Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>>>>> I suspect change introduced when addressing a compiler warning
>>>>> cased the error.
>>>>>
>>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20230516183442.536589-1-arnd%40kernel.org/
>>>
>>> I doubt it.
>>> This patch affects the device initialization code. But the crash is in
>>> the transmit path.
>>> Can you please double check by manually reverting the patch?
>>
>> I'm travelling at the moment and can't easily check it, but I would
>> expect that my patch has no effect on the generated object code [...]
>
> Michael, Arnd, thx for the replies. To you and everyone else that looked
> into this: sorry for the trouble this caused.
>
> The reporter's guess was wrong, as the reporter meanwhile confirmed in
> the bugzilla ticket that the problem started to happen earlier.
>
> Bagas, please be a bit more careful and don't blame a specific commit
> unless it's was found by bisection, a revert through a lucky guess, a
> statement from a developer, or something like that. In cases like this
> it would have been better to sent the developers of said commit a quick
> mail along the lines of "could you imagine that this change could lead
> to the problem the reporter described". But even that might be too much
> in a case like this, as too many of such false alarms and inquiries will
> make developers start hating or ignoring regression tracking in general
> or mails from you or me – and that is something that must be avoided, as
> without help from developers regression tracking becomes a lot harder or
> impossible.
>
> 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
> If I did something stupid, please tell me, as explained on that page.
>
> P.S.: Updating regzbot status, while at it:
The OP definitely needs to bisect this problem. The only system that I have that
runs b43 is a PowerBook G4 with a ppc32 CPU. That box has successfully run b43
for every release up to 6.4.0-rc7. I have seen no problems in recent kernels.
Larry
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-24 1:44 Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails Bagas Sanjaya
2023-06-24 8:50 ` Michael Büsch
@ 2023-06-24 21:32 ` Arnd Bergmann
[not found] ` <RO2P215MB193850DDADD38492BEC8CC2FA720A@RO2P215MB1938.LAMP215.PROD.OUTLOOK.COM>
1 sibling, 1 reply; 21+ messages in thread
From: Arnd Bergmann @ 2023-06-24 21:32 UTC (permalink / raw)
To: Bagas Sanjaya, Linux Kernel Mailing List, Linux Regressions,
Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman,
Larry Finger, Kalle Valo, sardonimous
On Sat, Jun 24, 2023, at 03:44, Bagas Sanjaya wrote:
> I notice a regression report on Bugzilla [1]. Quoting from it:
>
>> After upgrading to linux 6.3.8-arch1-1 from 6.3.6-arch1-1, b43 broadcom wireless driver fails. downgrading back to 6.3.6-arch1-1 resolves.
>>
>> Jun 16 20:56:37 askasleikir kernel: Hardware name: Apple Inc. MacBookPro7,1/Mac-F222BEC8, BIOS MBP71.88Z.0039.B15.1702241313 02/24/17
>> Jun 16 20:56:37 askasleikir kernel: Workqueue: phy0 b43_tx_work [b43]
>> Jun 16 20:56:37 askasleikir kernel: RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
FWIW, the report is missing a few lines at the top about
which error condition is being hit.
>> Jun 16 20:56:37 askasleikir kernel: <TASK>
>> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
>> Jun 16 20:56:37 askasleikir kernel: ? __warn+0x81/0x130
>> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
>> Jun 16 20:56:37 askasleikir kernel: ? report_bug+0x171/0x1a0
>> Jun 16 20:56:37 askasleikir kernel: ? handle_bug+0x3c/0x80
>> Jun 16 20:56:37 askasleikir kernel: ? exc_invalid_op+0x17/0x70
>> Jun 16 20:56:37 askasleikir kernel: ? asm_exc_invalid_op+0x1a/0x20
>> Jun 16 20:56:37 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
>> Jun 16 20:56:37 askasleikir kernel: ieee80211_stop_queue+0x36/0x50 [mac80211 136d1d948548ad6cca697df0da0a13c0a2333310]
This indicates that a WARN_ON() was hit in __ieee80211_stop_queue(),
and the only condition that could cause this is
if (WARN_ON(queue >= hw->queues))
return;
Maybe that helps figure out what went wrong.
Arnd
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
[not found] ` <RO2P215MB193850DDADD38492BEC8CC2FA720A@RO2P215MB1938.LAMP215.PROD.OUTLOOK.COM>
@ 2023-06-25 0:50 ` Bagas Sanjaya
2023-06-25 2:09 ` Larry Finger
2023-06-25 4:41 ` Larry Finger
0 siblings, 2 replies; 21+ messages in thread
From: Bagas Sanjaya @ 2023-06-25 0:50 UTC (permalink / raw)
To: Sardonimous .,
Arnd Bergmann, Linux Kernel Mailing List, Linux Regressions,
Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman,
Larry Finger, Kalle Valo
On 6/25/23 04:47, Sardonimous . wrote:
> A newer report with the missing top lines:
>
tl;dr:
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
Also, please send plain-text email: I don't see your dmesg on
lore.kernel.org archive because you send HTML email instead.
But anyway, I'm pasting yours from Bugzilla thread instead
(as Arnd requested):
```
Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
Jun 20 18:20:11 askasleikir kernel: WARNING: CPU: 1 PID: 33 at net/mac80211/util.c:514 __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
Jun 20 18:20:11 askasleikir kernel: Modules linked in: ccm tun qrtr rpcrdma rdma_cm iw_cm ib_cm ib_core nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver fscache net>
Jun 20 18:20:11 askasleikir kernel: lockd grace crypto_user sunrpc fuse dm_mod loop bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod>
Jun 20 18:20:11 askasleikir kernel: CPU: 1 PID: 33 Comm: kworker/u4:2 Tainted: G W 6.3.6-arch1-1 #1 a07497485287c74e7a472f42ded4b2ddcf7a6fd7
Jun 20 18:20:11 askasleikir kernel: Hardware name: Apple Inc. MacBookPro7,1/Mac-F222BEC8, BIOS MBP71.88Z.0039.B15.1702241313 02/24/17
Jun 20 18:20:11 askasleikir kernel: Workqueue: phy0 b43_tx_work [b43]
Jun 20 18:20:11 askasleikir kernel: RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
Jun 20 18:20:11 askasleikir kernel: Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 fb ea 00 00 65 ff 0d 2c 2d ac 3e 0f 85 55 ff ff ff e8 d9 44 69 c3 e9 4b ff>
Jun 20 18:20:11 askasleikir kernel: RSP: 0018:ffffb3538013bdb8 EFLAGS: 00010097
Jun 20 18:20:11 askasleikir kernel: RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
Jun 20 18:20:11 askasleikir kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff9e55cfa248e0
Jun 20 18:20:11 askasleikir kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 000000008010000f
Jun 20 18:20:11 askasleikir kernel: R10: 0000000000000005 R11: 0000000000000181 R12: ffff9e55cfa248e0
Jun 20 18:20:11 askasleikir kernel: R13: 0000000000000000 R14: ffff9e55cfa26238 R15: ffff9e55cfa26090
Jun 20 18:20:11 askasleikir kernel: FS: 0000000000000000(0000) GS:ffff9e55fbf00000(0000) knlGS:0000000000000000
Jun 20 18:20:11 askasleikir kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 20 18:20:11 askasleikir kernel: CR2: 00007f37cce5d180 CR3: 0000000057620000 CR4: 00000000000406e0
Jun 20 18:20:11 askasleikir kernel: Call Trace:
Jun 20 18:20:11 askasleikir kernel: <TASK>
Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
Jun 20 18:20:11 askasleikir kernel: ? __warn+0x81/0x130
Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
Jun 20 18:20:11 askasleikir kernel: ? report_bug+0x171/0x1a0
Jun 20 18:20:11 askasleikir kernel: ? handle_bug+0x3c/0x80
Jun 20 18:20:11 askasleikir kernel: ? exc_invalid_op+0x17/0x70
Jun 20 18:20:11 askasleikir kernel: ? asm_exc_invalid_op+0x1a/0x20
Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
Jun 20 18:20:11 askasleikir kernel: ? __slab_free+0xe0/0x310
Jun 20 18:20:11 askasleikir kernel: ieee80211_stop_queue+0x36/0x50 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
Jun 20 18:20:11 askasleikir kernel: b43_tx_work+0x57/0x130 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
Jun 20 18:20:11 askasleikir kernel: process_one_work+0x1c7/0x3d0
Jun 20 18:20:11 askasleikir kernel: worker_thread+0x51/0x390
Jun 20 18:20:11 askasleikir kernel: ? __pfx_worker_thread+0x10/0x10
Jun 20 18:20:11 askasleikir kernel: kthread+0xde/0x110
Jun 20 18:20:11 askasleikir kernel: ? __pfx_kthread+0x10/0x10
Jun 20 18:20:11 askasleikir kernel: ret_from_fork+0x2c/0x50
Jun 20 18:20:11 askasleikir kernel: </TASK>
Jun 20 18:20:11 askasleikir kernel: ---[ end trace 0000000000000000 ]---
Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
```
Thanks.
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 0:50 ` Bagas Sanjaya
@ 2023-06-25 2:09 ` Larry Finger
2023-06-25 4:41 ` Larry Finger
1 sibling, 0 replies; 21+ messages in thread
From: Larry Finger @ 2023-06-25 2:09 UTC (permalink / raw)
To: Bagas Sanjaya, Sardonimous .,
Arnd Bergmann, Linux Kernel Mailing List, Linux Regressions,
Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
On 6/24/23 19:50, Bagas Sanjaya wrote:
> On 6/25/23 04:47, Sardonimous . wrote:
>> A newer report with the missing top lines:
>>
>
> tl;dr:
>
>> A: http://en.wikipedia.org/wiki/Top_post
>> Q: Were do I find info about this thing called top-posting?
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>>
>> A: No.
>> Q: Should I include quotations after my reply?
>>
>> http://daringfireball.net/2007/07/on_top
>
> Also, please send plain-text email: I don't see your dmesg on
> lore.kernel.org archive because you send HTML email instead.
>
> But anyway, I'm pasting yours from Bugzilla thread instead
> (as Arnd requested):
>
> ```
> Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
> Jun 20 18:20:11 askasleikir kernel: WARNING: CPU: 1 PID: 33 at net/mac80211/util.c:514 __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
> Jun 20 18:20:11 askasleikir kernel: Modules linked in: ccm tun qrtr rpcrdma rdma_cm iw_cm ib_cm ib_core nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver fscache net>
> Jun 20 18:20:11 askasleikir kernel: lockd grace crypto_user sunrpc fuse dm_mod loop bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod>
> Jun 20 18:20:11 askasleikir kernel: CPU: 1 PID: 33 Comm: kworker/u4:2 Tainted: G W 6.3.6-arch1-1 #1 a07497485287c74e7a472f42ded4b2ddcf7a6fd7
> Jun 20 18:20:11 askasleikir kernel: Hardware name: Apple Inc. MacBookPro7,1/Mac-F222BEC8, BIOS MBP71.88Z.0039.B15.1702241313 02/24/17
> Jun 20 18:20:11 askasleikir kernel: Workqueue: phy0 b43_tx_work [b43]
> Jun 20 18:20:11 askasleikir kernel: RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
> Jun 20 18:20:11 askasleikir kernel: Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 fb ea 00 00 65 ff 0d 2c 2d ac 3e 0f 85 55 ff ff ff e8 d9 44 69 c3 e9 4b ff>
> Jun 20 18:20:11 askasleikir kernel: RSP: 0018:ffffb3538013bdb8 EFLAGS: 00010097
> Jun 20 18:20:11 askasleikir kernel: RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
> Jun 20 18:20:11 askasleikir kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff9e55cfa248e0
> Jun 20 18:20:11 askasleikir kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 000000008010000f
> Jun 20 18:20:11 askasleikir kernel: R10: 0000000000000005 R11: 0000000000000181 R12: ffff9e55cfa248e0
> Jun 20 18:20:11 askasleikir kernel: R13: 0000000000000000 R14: ffff9e55cfa26238 R15: ffff9e55cfa26090
> Jun 20 18:20:11 askasleikir kernel: FS: 0000000000000000(0000) GS:ffff9e55fbf00000(0000) knlGS:0000000000000000
> Jun 20 18:20:11 askasleikir kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 20 18:20:11 askasleikir kernel: CR2: 00007f37cce5d180 CR3: 0000000057620000 CR4: 00000000000406e0
> Jun 20 18:20:11 askasleikir kernel: Call Trace:
> Jun 20 18:20:11 askasleikir kernel: <TASK>
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? __warn+0x81/0x130
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? report_bug+0x171/0x1a0
> Jun 20 18:20:11 askasleikir kernel: ? handle_bug+0x3c/0x80
> Jun 20 18:20:11 askasleikir kernel: ? exc_invalid_op+0x17/0x70
> Jun 20 18:20:11 askasleikir kernel: ? asm_exc_invalid_op+0x1a/0x20
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? __slab_free+0xe0/0x310
> Jun 20 18:20:11 askasleikir kernel: ieee80211_stop_queue+0x36/0x50 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
> Jun 20 18:20:11 askasleikir kernel: b43_tx_work+0x57/0x130 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
> Jun 20 18:20:11 askasleikir kernel: process_one_work+0x1c7/0x3d0
> Jun 20 18:20:11 askasleikir kernel: worker_thread+0x51/0x390
> Jun 20 18:20:11 askasleikir kernel: ? __pfx_worker_thread+0x10/0x10
> Jun 20 18:20:11 askasleikir kernel: kthread+0xde/0x110
> Jun 20 18:20:11 askasleikir kernel: ? __pfx_kthread+0x10/0x10
> Jun 20 18:20:11 askasleikir kernel: ret_from_fork+0x2c/0x50
> Jun 20 18:20:11 askasleikir kernel: </TASK>
> Jun 20 18:20:11 askasleikir kernel: ---[ end trace 0000000000000000 ]---
> Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
Sardonimous,
The critical line is:
> Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390
I certainly have not used PIO for a long time. I expect that your MacBook Pro
should do DMA on the b43. Apple makes wierd hardware, but not likely that wierd.
Does dmesg offer any clues as to what is happening?
If there is nothing shown in the log, you definitely need to do a proper
bisection from the mainline git tree to isolate the change that led to this failure.
Larry
Larry
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 0:50 ` Bagas Sanjaya
2023-06-25 2:09 ` Larry Finger
@ 2023-06-25 4:41 ` Larry Finger
2023-06-25 16:58 ` Sardonimous
1 sibling, 1 reply; 21+ messages in thread
From: Larry Finger @ 2023-06-25 4:41 UTC (permalink / raw)
To: Bagas Sanjaya, Sardonimous .,
Arnd Bergmann, Linux Kernel Mailing List, Linux Regressions,
Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
On 6/24/23 19:50, Bagas Sanjaya wrote:
> On 6/25/23 04:47, Sardonimous . wrote:
>> A newer report with the missing top lines:
>>
>
> tl;dr:
>
>> A: http://en.wikipedia.org/wiki/Top_post
>> Q: Were do I find info about this thing called top-posting?
>> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>> Q: What is the most annoying thing in e-mail?
>>
>> A: No.
>> Q: Should I include quotations after my reply?
>>
>> http://daringfireball.net/2007/07/on_top
>
> Also, please send plain-text email: I don't see your dmesg on
> lore.kernel.org archive because you send HTML email instead.
>
> But anyway, I'm pasting yours from Bugzilla thread instead
> (as Arnd requested):
>
> ```
> Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
> Jun 20 18:20:11 askasleikir kernel: WARNING: CPU: 1 PID: 33 at net/mac80211/util.c:514 __ieee80211_stop_queue+0xcc/0xe0 [mac80211]
> Jun 20 18:20:11 askasleikir kernel: Modules linked in: ccm tun qrtr rpcrdma rdma_cm iw_cm ib_cm ib_core nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver fscache net>
> Jun 20 18:20:11 askasleikir kernel: lockd grace crypto_user sunrpc fuse dm_mod loop bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod>
> Jun 20 18:20:11 askasleikir kernel: CPU: 1 PID: 33 Comm: kworker/u4:2 Tainted: G W 6.3.6-arch1-1 #1 a07497485287c74e7a472f42ded4b2ddcf7a6fd7
> Jun 20 18:20:11 askasleikir kernel: Hardware name: Apple Inc. MacBookPro7,1/Mac-F222BEC8, BIOS MBP71.88Z.0039.B15.1702241313 02/24/17
> Jun 20 18:20:11 askasleikir kernel: Workqueue: phy0 b43_tx_work [b43]
> Jun 20 18:20:11 askasleikir kernel: RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211]
> Jun 20 18:20:11 askasleikir kernel: Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 fb ea 00 00 65 ff 0d 2c 2d ac 3e 0f 85 55 ff ff ff e8 d9 44 69 c3 e9 4b ff>
> Jun 20 18:20:11 askasleikir kernel: RSP: 0018:ffffb3538013bdb8 EFLAGS: 00010097
> Jun 20 18:20:11 askasleikir kernel: RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
> Jun 20 18:20:11 askasleikir kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff9e55cfa248e0
> Jun 20 18:20:11 askasleikir kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 000000008010000f
> Jun 20 18:20:11 askasleikir kernel: R10: 0000000000000005 R11: 0000000000000181 R12: ffff9e55cfa248e0
> Jun 20 18:20:11 askasleikir kernel: R13: 0000000000000000 R14: ffff9e55cfa26238 R15: ffff9e55cfa26090
> Jun 20 18:20:11 askasleikir kernel: FS: 0000000000000000(0000) GS:ffff9e55fbf00000(0000) knlGS:0000000000000000
> Jun 20 18:20:11 askasleikir kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 20 18:20:11 askasleikir kernel: CR2: 00007f37cce5d180 CR3: 0000000057620000 CR4: 00000000000406e0
> Jun 20 18:20:11 askasleikir kernel: Call Trace:
> Jun 20 18:20:11 askasleikir kernel: <TASK>
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? __warn+0x81/0x130
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? report_bug+0x171/0x1a0
> Jun 20 18:20:11 askasleikir kernel: ? handle_bug+0x3c/0x80
> Jun 20 18:20:11 askasleikir kernel: ? exc_invalid_op+0x17/0x70
> Jun 20 18:20:11 askasleikir kernel: ? asm_exc_invalid_op+0x1a/0x20
> Jun 20 18:20:11 askasleikir kernel: ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: ? __slab_free+0xe0/0x310
> Jun 20 18:20:11 askasleikir kernel: ieee80211_stop_queue+0x36/0x50 [mac80211 01be121fb223b347160617528f5dda900e828bc2]
> Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
> Jun 20 18:20:11 askasleikir kernel: b43_tx_work+0x57/0x130 [b43 3dc9b3f0fd98e2a659c64e057bd3b22d977e5228]
> Jun 20 18:20:11 askasleikir kernel: process_one_work+0x1c7/0x3d0
> Jun 20 18:20:11 askasleikir kernel: worker_thread+0x51/0x390
> Jun 20 18:20:11 askasleikir kernel: ? __pfx_worker_thread+0x10/0x10
> Jun 20 18:20:11 askasleikir kernel: kthread+0xde/0x110
> Jun 20 18:20:11 askasleikir kernel: ? __pfx_kthread+0x10/0x10
> Jun 20 18:20:11 askasleikir kernel: ret_from_fork+0x2c/0x50
> Jun 20 18:20:11 askasleikir kernel: </TASK>
> Jun 20 18:20:11 askasleikir kernel: ---[ end trace 0000000000000000 ]---
> Jun 20 18:20:11 askasleikir kernel: ------------[ cut here ]------------
Sardonimous,
The critical line is:
> Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390
I certainly have not used PIO for a long time. I expect that your MacBook Pro
should do DMA on the b43. Apple makes wierd hardware, but not likely that wierd.
Does dmesg offer any clues as to what is happening?
If there is nothing shown in the log, you definitely need to do a proper
bisection from the mainline git tree to isolate the change that led to this failure.
ADDED WITH EDIT: I looked at the code and b43 will not be built for any hardware
without DMA, thus it appears that adding "b43.pio=1" is the only way to get PIO
mode. Please check the output of dmesg for PIO messages.
Larry
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 4:41 ` Larry Finger
@ 2023-06-25 16:58 ` Sardonimous
2023-06-25 18:12 ` Arnd Bergmann
0 siblings, 1 reply; 21+ messages in thread
From: Sardonimous @ 2023-06-25 16:58 UTC (permalink / raw)
To: Larry Finger, Bagas Sanjaya, Arnd Bergmann,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
Hello Larry,
On 6/24/23 23:41, Larry Finger wrote:
>
> Sardonimous,
>
> The critical line is:
>> Jun 20 18:20:11 askasleikir kernel: b43_pio_tx+0x373/0x390
>
> I certainly have not used PIO for a long time. I expect that your
> MacBook Pro should do DMA on the b43. Apple makes wierd hardware, but
> not likely that wierd.
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
>
> Does dmesg offer any clues as to what is happening?
>
If I try with, say:
options b43 pio=0 qos=0 verbose=3
Then
rmmod b43
rmmod ssb
modprobe b43
I see the following:
insmod /lib/modules/6.1.12-arch1-1/kernel/drivers/ssb/ssb.ko.zst
insmod
/lib/modules/6.1.12-arch1-1/kernel/drivers/net/wireless/broadcom/b43/b43.ko.zst
pio=0 qos=0 verbose=3
...
[Jun25 11:51] ssb: Found chip with id 0x4322, rev 0x01 and package 0x0A
[ +0.096950] b43-pci-bridge 0000:02:00.0: Sonics Silicon Backplane
found on PCI device 0000:02:00.0
[ +0.411653] b43-phy1: Broadcom 4322 WLAN found (core revision 16)
[ +0.038206] b43-phy1: Found PHY: Analog 8, Type 4 (N), Revision 4
[ +0.000032] b43-phy1: Found Radio: Manuf 0x17F, ID 0x2056, Revision 3,
Version 0
[ +0.015660] Broadcom 43xx driver loaded [ Features: PNLS ]
[ +0.520933] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ +0.726559] b43-phy1: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ +0.276596] b43-phy1 debug: Chip initialized
[ +0.000562] b43-phy1 debug: 64-bit DMA initialized
[ +0.000013] b43-phy1 debug: QoS disabled
[ +0.023145] b43-phy1 debug: Wireless interface started
[ +0.056159] b43-phy1 debug: Adding Interface type 2
[ +0.086691] b43-phy1 debug: Removing Interface type 2
[ +0.000105] b43-phy1 debug: Wireless interface stopped
[ +0.099849] b43-phy1 ERROR: DMA RX reset timed out
[ +0.065067] b43 ssb0:0: Timeout waiting for bitmask 01800000 on
register 0F90 to clear
[ +0.204905] b43-phy1: Loading firmware version 784.2 (2012-08-15 21:35:19)
[ +0.296681] b43-phy1 debug: Chip initialized
[ +0.000555] b43-phy1 debug: 64-bit DMA initialized
[ +0.000010] b43-phy1 debug: QoS disabled
[ +0.027099] b43-phy1 debug: Wireless interface started
[ +0.062503] b43-phy1 debug: Adding Interface type 2
The wlan0 device never seems to work, no IP address is obtained, etc.
> If there is nothing shown in the log, you definitely need to do a
> proper bisection from the mainline git tree to isolate the change that
> led to this failure.
Still working on initial kernel build.
> ADDED WITH EDIT: I looked at the code and b43 will not be built for
> any hardware without DMA, thus it appears that adding "b43.pio=1" is
> the only way to get PIO mode. Please check the output of dmesg for PIO
> messages.
>
> Larry
Thanks & regards,
Sardonimous
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 16:58 ` Sardonimous
@ 2023-06-25 18:12 ` Arnd Bergmann
2023-06-25 18:17 ` Larry Finger
0 siblings, 1 reply; 21+ messages in thread
From: Arnd Bergmann @ 2023-06-25 18:12 UTC (permalink / raw)
To: Sardonimous .,
Larry Finger, Bagas Sanjaya, Linux Kernel Mailing List,
Linux Regressions, Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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.
Arnd
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 18:12 ` Arnd Bergmann
@ 2023-06-25 18:17 ` Larry Finger
2023-06-25 21:11 ` Sardonimous
0 siblings, 1 reply; 21+ messages in thread
From: Larry Finger @ 2023-06-25 18:17 UTC (permalink / raw)
To: Arnd Bergmann, Sardonimous .,
Bagas Sanjaya, Linux Kernel Mailing List, Linux Regressions,
Linux Wireless, Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 18:17 ` Larry Finger
@ 2023-06-25 21:11 ` Sardonimous
2023-06-25 23:05 ` Larry Finger
0 siblings, 1 reply; 21+ messages in thread
From: Sardonimous @ 2023-06-25 21:11 UTC (permalink / raw)
To: Larry Finger, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 21:11 ` Sardonimous
@ 2023-06-25 23:05 ` Larry Finger
2023-06-26 12:44 ` Sardonimous
0 siblings, 1 reply; 21+ messages in thread
From: Larry Finger @ 2023-06-25 23:05 UTC (permalink / raw)
To: Sardonimous, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-25 23:05 ` Larry Finger
@ 2023-06-26 12:44 ` Sardonimous
2023-06-26 15:21 ` Larry Finger
0 siblings, 1 reply; 21+ messages in thread
From: Sardonimous @ 2023-06-26 12:44 UTC (permalink / raw)
To: Larry Finger, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-26 12:44 ` Sardonimous
@ 2023-06-26 15:21 ` Larry Finger
2023-06-26 21:33 ` Sardonimous
0 siblings, 1 reply; 21+ messages in thread
From: Larry Finger @ 2023-06-26 15:21 UTC (permalink / raw)
To: Sardonimous, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-26 15:21 ` Larry Finger
@ 2023-06-26 21:33 ` Sardonimous
2023-06-27 0:31 ` Larry Finger
2023-07-03 17:35 ` Larry Finger
0 siblings, 2 replies; 21+ messages in thread
From: Sardonimous @ 2023-06-26 21:33 UTC (permalink / raw)
To: Larry Finger, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-26 21:33 ` Sardonimous
@ 2023-06-27 0:31 ` Larry Finger
2023-07-03 17:35 ` Larry Finger
1 sibling, 0 replies; 21+ messages in thread
From: Larry Finger @ 2023-06-27 0:31 UTC (permalink / raw)
To: Sardonimous, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-06-26 21:33 ` Sardonimous
2023-06-27 0:31 ` Larry Finger
@ 2023-07-03 17:35 ` Larry Finger
2023-07-03 20:13 ` Sardonimous
1 sibling, 1 reply; 21+ messages in thread
From: Larry Finger @ 2023-07-03 17:35 UTC (permalink / raw)
To: Sardonimous, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-07-03 17:35 ` Larry Finger
@ 2023-07-03 20:13 ` Sardonimous
2023-07-04 8:30 ` Linux regression tracking #update (Thorsten Leemhuis)
0 siblings, 1 reply; 21+ messages in thread
From: Sardonimous @ 2023-07-03 20:13 UTC (permalink / raw)
To: Larry Finger, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails
2023-07-03 20:13 ` Sardonimous
@ 2023-07-04 8:30 ` Linux regression tracking #update (Thorsten Leemhuis)
0 siblings, 0 replies; 21+ messages in thread
From: Linux regression tracking #update (Thorsten Leemhuis) @ 2023-07-04 8:30 UTC (permalink / raw)
To: Sardonimous, Larry Finger, Arnd Bergmann, Bagas Sanjaya,
Linux Kernel Mailing List, Linux Regressions, Linux Wireless,
Netdev
Cc: Michael Büsch, kernel test robot, Simon Horman, Kalle Valo
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2023-07-04 8:30 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-24 1:44 Fwd: After kernel 6.3.7 or 6.3.8 b43 driver fails Bagas Sanjaya
2023-06-24 8:50 ` Michael Büsch
2023-06-24 9:29 ` Arnd Bergmann
2023-06-24 14:00 ` Linux regression tracking (Thorsten Leemhuis)
2023-06-24 16:22 ` Larry Finger
2023-06-24 21:32 ` Fwd: " Arnd Bergmann
[not found] ` <RO2P215MB193850DDADD38492BEC8CC2FA720A@RO2P215MB1938.LAMP215.PROD.OUTLOOK.COM>
2023-06-25 0:50 ` Bagas Sanjaya
2023-06-25 2:09 ` Larry Finger
2023-06-25 4:41 ` Larry Finger
2023-06-25 16:58 ` Sardonimous
2023-06-25 18:12 ` Arnd Bergmann
2023-06-25 18:17 ` Larry Finger
2023-06-25 21:11 ` Sardonimous
2023-06-25 23:05 ` Larry Finger
2023-06-26 12:44 ` Sardonimous
2023-06-26 15:21 ` Larry Finger
2023-06-26 21:33 ` Sardonimous
2023-06-27 0:31 ` Larry Finger
2023-07-03 17:35 ` Larry Finger
2023-07-03 20:13 ` Sardonimous
2023-07-04 8:30 ` Linux regression tracking #update (Thorsten Leemhuis)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.