* [PATCH] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
@ 2018-05-09 11:41 Taketo Kabe
2018-05-09 16:51 ` Michael Büsch
0 siblings, 1 reply; 12+ messages in thread
From: Taketo Kabe @ 2018-05-09 11:41 UTC (permalink / raw)
To: b43-dev
From: Taketo Kabe <kabe@sra-tohoku.co.jp>
Fix for b43 wireless card stopping transmission when switching VTs.
Setup:
Using BCM4306 rev.03 chip based CardBus wireless card.
IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
For firmware, installed latest but dated openfwwf 5.2
(http://netweb.ing.unibs.it/~openfwwf/)
How-to-reproduce:
Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
repeatedly switch VTs by Alt-F1<>Alt-F2.
Eventually (within a minute) the card stops working.
You can receive traffic but no transmission.
For unknown reason it doesn't occur when just generating traffic by
"ssh <remotehost> ls -lR /".
With CONFIG_B43_DEBUG=y kernel config, when it stops,
the debug message shows
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
The slot offset I observed so far was always 32.
When err_out2 is not set to make error messages successive,
the debug output will be like this:
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
The TX ring alternates between 2 sequences; the ring seems
to be completely confused. Controller restart is needed.
Workaround(1):
This problem doesn't occur when using propriatory firmware
you will extract by b43-fwcutter, so it may be a bug in
openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
I wasn't able to find a bug in the terse openfwwf code though.
Workaround(2):
Using "pio=1" option to not use DMA makes this problem to
not occur.
Description of the patch:
This patch will forcibly reset the controller to make it
work again. Very kludgy and doesn't look right, but
the traffic will continue to flow.
Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
---
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
--- ./drivers/net/wireless/broadcom/b43/dma.c.b43 2018-05-04 15:18:12.000000000 +0900
+++ ./drivers/net/wireless/broadcom/b43/dma.c 2018-05-04 15:19:24.000000000 +0900
@@ -1524,7 +1524,9 @@ void b43_dma_handle_txstatus(struct b43_
b43dbg(dev->wl,
"Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
ring->index, firstused, slot);
- err_out2 = 1;
+ /*err_out2 = 1;*/
+ /* Reset the controller to revive operation */
+ b43_controller_restart(dev, "Out of order TX");
return;
}
}
--
kabe
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
2018-05-09 11:41 [PATCH] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched Taketo Kabe
@ 2018-05-09 16:51 ` Michael Büsch
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
0 siblings, 1 reply; 12+ messages in thread
From: Michael Büsch @ 2018-05-09 16:51 UTC (permalink / raw)
To: b43-dev
Hi,
thanks for your patch and your analysis of the problem.
On Wed, 09 May 2018 20:41:39 +0900
Taketo Kabe <kabe@sra-tohoku.co.jp> wrote:
> Workaround(1):
> This problem doesn't occur when using propriatory firmware
Please also report this bug to openfwwf.
> Description of the patch:
> This patch will forcibly reset the controller to make it
> work again. Very kludgy and doesn't look right, but
> the traffic will continue to flow.
>
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> ---
> diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
> --- ./drivers/net/wireless/broadcom/b43/dma.c.b43 2018-05-04 15:18:12.000000000 +0900
> +++ ./drivers/net/wireless/broadcom/b43/dma.c 2018-05-04 15:19:24.000000000 +0900
> @@ -1524,7 +1524,9 @@ void b43_dma_handle_txstatus(struct b43_
> b43dbg(dev->wl,
> "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
> ring->index, firstused, slot);
> - err_out2 = 1;
> + /*err_out2 = 1;*/
Please completely remove the variable err_out2, but leave the b43dbg
unconditionally.
> + /* Reset the controller to revive operation */
> + b43_controller_restart(dev, "Out of order TX");
> return;
> }
> }
I think this change is fine. It adds some robustness.
Please take care of the above point and resend the patch.
Please also CC linux-wireless at vger.kernel.org and kvalo at codeaurora.org
Thanks for your work. :)
--
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20180509/22a8223b/attachment.sig>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
2018-05-09 16:51 ` Michael Büsch
@ 2018-05-10 10:30 ` Taketo Kabe
2018-05-10 11:15 ` Michael Büsch
` (4 more replies)
0 siblings, 5 replies; 12+ messages in thread
From: Taketo Kabe @ 2018-05-10 10:30 UTC (permalink / raw)
To: b43-dev; +Cc: kabe, linux-wireless, kvalo
From: Taketo Kabe <kabe@sra-tohoku.co.jp>
Fix for b43 wireless card stopping transmission when switching VTs.
Setup:
Using BCM4306 rev.03 chip based CardBus wireless card.
IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
For firmware, installed latest but dated openfwwf 5.2
(http://netweb.ing.unibs.it/~openfwwf/)
How-to-reproduce:
Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
repeatedly switch VTs by Alt-F1<>Alt-F2.
Eventually (within a minute) the card stops working.
You can receive traffic but no transmission.
For unknown reason it doesn't occur when just generating traffic by
"ssh <remotehost> ls -lR /".
With CONFIG_B43_DEBUG=y kernel config, when it stops,
the debug message shows
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
The slot offset I observed so far was always 32.
When err_out2 is not set to make error messages successive,
the debug output will be like this:
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
The TX ring alternates between 2 sequences; the ring seems
to be completely confused. Controller restart is needed.
Workaround(1):
This problem doesn't occur when using propriatory firmware
you will extract by b43-fwcutter, so it may be a bug in
openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
I wasn't able to find a bug in the terse openfwwf code though.
Workaround(2):
Using "pio=1" option to not use DMA makes this problem to
not occur.
Description of the patch:
This patch will forcibly reset the controller to make it
work again. Very kludgy and doesn't look right, but
the traffic will continue to flow.
Changes since last edition:
- Remove now unused err_out2 variable.
Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
---
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
--- ./drivers/net/wireless/broadcom/b43/dma.c.b43 2018-05-04 15:18:12.000000000 +0900
+++ ./drivers/net/wireless/broadcom/b43/dma.c 2018-05-10 18:46:36.000000000 +0900
@@ -1484,7 +1484,7 @@ void b43_dma_handle_txstatus(struct b43_
int slot, firstused;
bool frame_succeed;
int skip;
- static u8 err_out1, err_out2;
+ static u8 err_out1;
ring = parse_cookie(dev, status->cookie, &slot);
if (unlikely(!ring))
@@ -1518,13 +1518,13 @@ void b43_dma_handle_txstatus(struct b43_
}
} else {
/* More than a single header/data pair were missed.
- * Report this error once.
+ * Report this error, and reset the controller to
+ * revive operation.
*/
- if (!err_out2)
- b43dbg(dev->wl,
- "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
- ring->index, firstused, slot);
- err_out2 = 1;
+ b43dbg(dev->wl,
+ "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
+ ring->index, firstused, slot);
+ b43_controller_restart(dev, "Out of order TX");
return;
}
}
--
kabe
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
@ 2018-05-10 11:15 ` Michael Büsch
2018-05-11 10:15 ` Kalle Valo
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Michael Büsch @ 2018-05-10 11:15 UTC (permalink / raw)
To: Taketo Kabe, kvalo; +Cc: b43-dev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
On Thu, 10 May 2018 19:30:45 +0900
Taketo Kabe <kabe@sra-tohoku.co.jp> wrote:
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> ---
> diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
> --- ./drivers/net/wireless/broadcom/b43/dma.c.b43 2018-05-04 15:18:12.000000000 +0900
> +++ ./drivers/net/wireless/broadcom/b43/dma.c 2018-05-10 18:46:36.000000000 +0900
> @@ -1484,7 +1484,7 @@ void b43_dma_handle_txstatus(struct b43_
> int slot, firstused;
> bool frame_succeed;
> int skip;
> - static u8 err_out1, err_out2;
> + static u8 err_out1;
>
> ring = parse_cookie(dev, status->cookie, &slot);
> if (unlikely(!ring))
> @@ -1518,13 +1518,13 @@ void b43_dma_handle_txstatus(struct b43_
> }
> } else {
> /* More than a single header/data pair were missed.
> - * Report this error once.
> + * Report this error, and reset the controller to
> + * revive operation.
> */
> - if (!err_out2)
> - b43dbg(dev->wl,
> - "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
> - ring->index, firstused, slot);
> - err_out2 = 1;
> + b43dbg(dev->wl,
> + "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
> + ring->index, firstused, slot);
> + b43_controller_restart(dev, "Out of order TX");
> return;
> }
> }
Reviewed-by: Michael Büsch <m@bues.ch>
I think this is a good thing to have.
It improves robustness against firmware/DMA misbehavior.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
@ 2018-05-10 11:15 ` Michael Büsch
0 siblings, 0 replies; 12+ messages in thread
From: Michael Büsch @ 2018-05-10 11:15 UTC (permalink / raw)
To: Taketo Kabe, kvalo; +Cc: b43-dev, linux-wireless
On Thu, 10 May 2018 19:30:45 +0900
Taketo Kabe <kabe@sra-tohoku.co.jp> wrote:
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> ---
> diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
> --- ./drivers/net/wireless/broadcom/b43/dma.c.b43 2018-05-04 15:18:12.000000000 +0900
> +++ ./drivers/net/wireless/broadcom/b43/dma.c 2018-05-10 18:46:36.000000000 +0900
> @@ -1484,7 +1484,7 @@ void b43_dma_handle_txstatus(struct b43_
> int slot, firstused;
> bool frame_succeed;
> int skip;
> - static u8 err_out1, err_out2;
> + static u8 err_out1;
>
> ring = parse_cookie(dev, status->cookie, &slot);
> if (unlikely(!ring))
> @@ -1518,13 +1518,13 @@ void b43_dma_handle_txstatus(struct b43_
> }
> } else {
> /* More than a single header/data pair were missed.
> - * Report this error once.
> + * Report this error, and reset the controller to
> + * revive operation.
> */
> - if (!err_out2)
> - b43dbg(dev->wl,
> - "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
> - ring->index, firstused, slot);
> - err_out2 = 1;
> + b43dbg(dev->wl,
> + "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
> + ring->index, firstused, slot);
> + b43_controller_restart(dev, "Out of order TX");
> return;
> }
> }
Reviewed-by: Michael B?sch <m@bues.ch>
I think this is a good thing to have.
It improves robustness against firmware/DMA misbehavior.
--
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20180510/4c3fee2e/attachment.sig>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
@ 2018-05-11 10:15 ` Kalle Valo
2018-05-11 10:15 ` Kalle Valo
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-11 10:15 UTC (permalink / raw)
To: Taketo Kabe; +Cc: b43-dev, linux-wireless
Taketo Kabe <kabe@sra-tohoku.co.jp> writes:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Fix for b43 wireless card stopping transmission when switching VTs.
The title is wrong, it should be:
b43: fix transmit failure when VT is switched
I can fix that during commit.
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched
@ 2018-05-11 10:15 ` Kalle Valo
0 siblings, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-11 10:15 UTC (permalink / raw)
To: Taketo Kabe; +Cc: b43-dev, linux-wireless
Taketo Kabe <kabe@sra-tohoku.co.jp> writes:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Fix for b43 wireless card stopping transmission when switching VTs.
The title is wrong, it should be:
b43: fix transmit failure when VT is switched
I can fix that during commit.
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [v2] b43: fix transmit failure when VT is switched
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
` (2 preceding siblings ...)
2018-05-12 8:50 ` [v2] b43: " Kalle Valo
@ 2018-05-12 8:50 ` Kalle Valo
[not found] ` <20180512085053.8637A60618@smtp.codeaurora.org>
4 siblings, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-12 8:50 UTC (permalink / raw)
To: kabe; +Cc: b43-dev, kabe, linux-wireless
kabe@sra-tohoku.co.jp wrote:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Fix for b43 wireless card stopping transmission when switching VTs.
>
> Setup:
> Using BCM4306 rev.03 chip based CardBus wireless card.
> IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
> For firmware, installed latest but dated openfwwf 5.2
> (http://netweb.ing.unibs.it/~openfwwf/)
>
> How-to-reproduce:
> Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
> repeatedly switch VTs by Alt-F1<>Alt-F2.
> Eventually (within a minute) the card stops working.
> You can receive traffic but no transmission.
> For unknown reason it doesn't occur when just generating traffic by
> "ssh <remotehost> ls -lR /".
>
> With CONFIG_B43_DEBUG=y kernel config, when it stops,
> the debug message shows
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
> The slot offset I observed so far was always 32.
>
> When err_out2 is not set to make error messages successive,
> the debug output will be like this:
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
> The TX ring alternates between 2 sequences; the ring seems
> to be completely confused. Controller restart is needed.
>
> Workaround(1):
> This problem doesn't occur when using propriatory firmware
> you will extract by b43-fwcutter, so it may be a bug in
> openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
> I wasn't able to find a bug in the terse openfwwf code though.
>
> Workaround(2):
> Using "pio=1" option to not use DMA makes this problem to
> not occur.
>
> Description of the patch:
> This patch will forcibly reset the controller to make it
> work again. Very kludgy and doesn't look right, but
> the traffic will continue to flow.
>
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> Reviewed-by: Michael Buesch <m@bues.ch>
> [kvalo@codeaurora.org: clean up commit log]
Failed to apply to wireless-drivers-next:
fatal: sha1 information is lacking or useless (drivers/net/wireless/broadcom/b43/dma.c).
error: could not build fake ancestor
Applying: b43: fix transmit failure when VT is switched
Patch failed at 0001 b43: fix transmit failure when VT is switched
The copy of the patch that failed is found in: .git/rebase-apply/patch
Please read:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#format_of_patches
Also the change log should be after --- line:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10391617/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 12+ messages in thread
* [v2] b43: fix transmit failure when VT is switched
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
2018-05-10 11:15 ` Michael Büsch
2018-05-11 10:15 ` Kalle Valo
@ 2018-05-12 8:50 ` Kalle Valo
2018-05-12 8:50 ` Kalle Valo
[not found] ` <20180512085053.8637A60618@smtp.codeaurora.org>
4 siblings, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-12 8:50 UTC (permalink / raw)
To: b43-dev
kabe at sra-tohoku.co.jp wrote:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Fix for b43 wireless card stopping transmission when switching VTs.
>
> Setup:
> Using BCM4306 rev.03 chip based CardBus wireless card.
> IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
> For firmware, installed latest but dated openfwwf 5.2
> (http://netweb.ing.unibs.it/~openfwwf/)
>
> How-to-reproduce:
> Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
> repeatedly switch VTs by Alt-F1<>Alt-F2.
> Eventually (within a minute) the card stops working.
> You can receive traffic but no transmission.
> For unknown reason it doesn't occur when just generating traffic by
> "ssh <remotehost> ls -lR /".
>
> With CONFIG_B43_DEBUG=y kernel config, when it stops,
> the debug message shows
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
> The slot offset I observed so far was always 32.
>
> When err_out2 is not set to make error messages successive,
> the debug output will be like this:
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
> The TX ring alternates between 2 sequences; the ring seems
> to be completely confused. Controller restart is needed.
>
> Workaround(1):
> This problem doesn't occur when using propriatory firmware
> you will extract by b43-fwcutter, so it may be a bug in
> openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
> I wasn't able to find a bug in the terse openfwwf code though.
>
> Workaround(2):
> Using "pio=1" option to not use DMA makes this problem to
> not occur.
>
> Description of the patch:
> This patch will forcibly reset the controller to make it
> work again. Very kludgy and doesn't look right, but
> the traffic will continue to flow.
>
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> Reviewed-by: Michael Buesch <m@bues.ch>
> [kvalo at codeaurora.org: clean up commit log]
Failed to apply to wireless-drivers-next:
fatal: sha1 information is lacking or useless (drivers/net/wireless/broadcom/b43/dma.c).
error: could not build fake ancestor
Applying: b43: fix transmit failure when VT is switched
Patch failed at 0001 b43: fix transmit failure when VT is switched
The copy of the patch that failed is found in: .git/rebase-apply/patch
Please read:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#format_of_patches
Also the change log should be after --- line:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10391617/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3] b43: fix transmit failure when VT is switched
[not found] ` <20180512085053.8637A60618@smtp.codeaurora.org>
@ 2018-05-13 9:16 ` Taketo Kabe
2018-05-15 5:40 ` [v3] " Kalle Valo
2018-05-15 5:40 ` Kalle Valo
0 siblings, 2 replies; 12+ messages in thread
From: Taketo Kabe @ 2018-05-13 9:16 UTC (permalink / raw)
To: linux-wireless; +Cc: kabe, b43-dev
From: Taketo Kabe <kabe@sra-tohoku.co.jp>
Setup:
Using BCM4306 rev.03 chip based CardBus wireless card.
IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
For firmware, installed latest but dated openfwwf 5.2
(http://netweb.ing.unibs.it/~openfwwf/)
How-to-reproduce:
Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
repeatedly switch VTs by Alt-F1<>Alt-F2.
Eventually (within a minute) the card stops working.
You can receive traffic but no transmission.
For unknown reason it doesn't occur when just generating traffic by
"ssh <remotehost> ls -lR /".
With CONFIG_B43_DEBUG=y kernel config, when it stops,
the debug message shows
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
The slot offset I observed so far was always 32.
When err_out2 is not set to make error messages successive,
the debug output will be like this:
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
The TX ring alternates between 2 sequences; the ring seems
to be completely confused. Controller restart is needed.
Workaround(1):
This problem doesn't occur when using propriatory firmware
you will extract by b43-fwcutter, so it may be a bug in
openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
I wasn't able to find a bug in the terse openfwwf code though.
Workaround(2):
Using "pio=1" option to not use DMA makes this problem to
not occur.
Description of the patch:
This patch will forcibly reset the controller to make it
work again. Very kludgy and doesn't look right, but
the traffic will continue to flow.
Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
Reviewed-by: Michael Buesch <m@bues.ch>
---
drivers/net/wireless/broadcom/b43/dma.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Changes since last edition:
- Remove now unused err_out2 variable.
- Regenerated the patch using "git format-patch" against
wireless-drivers-next.git .
diff --git a/drivers/net/wireless/broadcom/b43/dma.c b/drivers/net/wireless/broadcom/b43/dma.c
index 6837064..6b0e1ec 100644
--- a/drivers/net/wireless/broadcom/b43/dma.c
+++ b/drivers/net/wireless/broadcom/b43/dma.c
@@ -1484,7 +1484,7 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev,
int slot, firstused;
bool frame_succeed;
int skip;
- static u8 err_out1, err_out2;
+ static u8 err_out1;
ring = parse_cookie(dev, status->cookie, &slot);
if (unlikely(!ring))
@@ -1518,13 +1518,13 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev,
}
} else {
/* More than a single header/data pair were missed.
- * Report this error once.
+ * Report this error, and reset the controller to
+ * revive operation.
*/
- if (!err_out2)
- b43dbg(dev->wl,
- "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
- ring->index, firstused, slot);
- err_out2 = 1;
+ b43dbg(dev->wl,
+ "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
+ ring->index, firstused, slot);
+ b43_controller_restart(dev, "Out of order TX");
return;
}
}
--
kabe
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [v3] b43: fix transmit failure when VT is switched
2018-05-13 9:16 ` [PATCH v3] " Taketo Kabe
@ 2018-05-15 5:40 ` Kalle Valo
2018-05-15 5:40 ` Kalle Valo
1 sibling, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-15 5:40 UTC (permalink / raw)
To: kabe; +Cc: linux-wireless, kabe, b43-dev
kabe@sra-tohoku.co.jp wrote:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Setup:
> Using BCM4306 rev.03 chip based CardBus wireless card.
> IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
> For firmware, installed latest but dated openfwwf 5.2
> (http://netweb.ing.unibs.it/~openfwwf/)
>
> How-to-reproduce:
> Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
> repeatedly switch VTs by Alt-F1<>Alt-F2.
> Eventually (within a minute) the card stops working.
> You can receive traffic but no transmission.
> For unknown reason it doesn't occur when just generating traffic by
> "ssh <remotehost> ls -lR /".
>
> With CONFIG_B43_DEBUG=y kernel config, when it stops,
> the debug message shows
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
> The slot offset I observed so far was always 32.
>
> When err_out2 is not set to make error messages successive,
> the debug output will be like this:
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
> The TX ring alternates between 2 sequences; the ring seems
> to be completely confused. Controller restart is needed.
>
> Workaround(1):
> This problem doesn't occur when using propriatory firmware
> you will extract by b43-fwcutter, so it may be a bug in
> openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
> I wasn't able to find a bug in the terse openfwwf code though.
>
> Workaround(2):
> Using "pio=1" option to not use DMA makes this problem to
> not occur.
>
> Description of the patch:
> This patch will forcibly reset the controller to make it
> work again. Very kludgy and doesn't look right, but
> the traffic will continue to flow.
>
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> Reviewed-by: Michael Buesch <m@bues.ch>
Patch applied to wireless-drivers-next.git, thanks.
66cffd6daab7 b43: fix transmit failure when VT is switched
--
https://patchwork.kernel.org/patch/10396133/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 12+ messages in thread
* [v3] b43: fix transmit failure when VT is switched
2018-05-13 9:16 ` [PATCH v3] " Taketo Kabe
2018-05-15 5:40 ` [v3] " Kalle Valo
@ 2018-05-15 5:40 ` Kalle Valo
1 sibling, 0 replies; 12+ messages in thread
From: Kalle Valo @ 2018-05-15 5:40 UTC (permalink / raw)
To: b43-dev
kabe at sra-tohoku.co.jp wrote:
> From: Taketo Kabe <kabe@sra-tohoku.co.jp>
>
> Setup:
> Using BCM4306 rev.03 chip based CardBus wireless card.
> IRQ is shared with yenta (cardbus bridge) and i915 (display) driver.
> For firmware, installed latest but dated openfwwf 5.2
> (http://netweb.ing.unibs.it/~openfwwf/)
>
> How-to-reproduce:
> Do "ssh <NetBSD-remotehost>", then "ls -lR /" to generate traffic, then
> repeatedly switch VTs by Alt-F1<>Alt-F2.
> Eventually (within a minute) the card stops working.
> You can receive traffic but no transmission.
> For unknown reason it doesn't occur when just generating traffic by
> "ssh <remotehost> ls -lR /".
>
> With CONFIG_B43_DEBUG=y kernel config, when it stops,
> the debug message shows
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 148, but got 180
> The slot offset I observed so far was always 32.
>
> When err_out2 is not set to make error messages successive,
> the debug output will be like this:
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 148
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 150
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 120
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 152
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 122
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 154
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 124
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 156
> kernel: b43-phy1 debug: Out of order TX status report on DMA ring 1. Expected 116, but got 126
> The TX ring alternates between 2 sequences; the ring seems
> to be completely confused. Controller restart is needed.
>
> Workaround(1):
> This problem doesn't occur when using propriatory firmware
> you will extract by b43-fwcutter, so it may be a bug in
> openfwwf firmware, as the comment in the b43_dma_handle_txstatus() suggests.
> I wasn't able to find a bug in the terse openfwwf code though.
>
> Workaround(2):
> Using "pio=1" option to not use DMA makes this problem to
> not occur.
>
> Description of the patch:
> This patch will forcibly reset the controller to make it
> work again. Very kludgy and doesn't look right, but
> the traffic will continue to flow.
>
> Signed-off-by: Taketo Kabe <kabe@sra-tohoku.co.jp>
> Reviewed-by: Michael Buesch <m@bues.ch>
Patch applied to wireless-drivers-next.git, thanks.
66cffd6daab7 b43: fix transmit failure when VT is switched
--
https://patchwork.kernel.org/patch/10396133/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-05-15 5:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-09 11:41 [PATCH] drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched Taketo Kabe
2018-05-09 16:51 ` Michael Büsch
2018-05-10 10:30 ` [PATCH v2] " Taketo Kabe
2018-05-10 11:15 ` Michael Büsch
2018-05-10 11:15 ` Michael Büsch
2018-05-11 10:15 ` Kalle Valo
2018-05-11 10:15 ` Kalle Valo
2018-05-12 8:50 ` [v2] b43: " Kalle Valo
2018-05-12 8:50 ` Kalle Valo
[not found] ` <20180512085053.8637A60618@smtp.codeaurora.org>
2018-05-13 9:16 ` [PATCH v3] " Taketo Kabe
2018-05-15 5:40 ` [v3] " Kalle Valo
2018-05-15 5:40 ` Kalle Valo
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.