Skip to contentSkip to conversation

drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

PATCH Superseded Taketo Kabe 3 participants 10 messages May 9, 2018 – May 15, 2018 1 message not in the archive B43 wireless driver

lore
Share & tools
lore

Taketo Kabe

author
#0 lore raw

PATCH 1/1 drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

From: Taketo Kabe <[email protected]>

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 <[email protected]>

---

drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +3 -1
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
@@ -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;
 		}
 	}
Signature · 1 line
kabe
#1 lore raw

PATCH 1/1 drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

Hi,

thanks for your patch and your analysis of the problem.

Quoted 2 lines · On Wed, 09 May 2018 20:41:39 +0900 Taketo Kabe <[email protected]> wrote:

Workaround(1):
This problem doesn't occur when using propriatory firmware

Please also report this bug to openfwwf.

Quoted 11 lines

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 <[email protected]>

---
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c

drivers/net/wireless/broadcom/b43/dma.c void b43_dma_handle_txstatus(struct b43_ · line 1527

Quoted 5 lines
drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +1 -1
@@ -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.

drivers/net/wireless/broadcom/b43/dma.c void b43_dma_handle_txstatus(struct b43_ · line 1532

Quoted 5 lines
drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +2 -0
+			/* 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. :)

Signature · 8 lines
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>
author
#2 lore raw

PATCH v2 1/1 drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

From: Taketo Kabe <[email protected]>

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 <[email protected]>

---

drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +7 -7
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c
@@ -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;
  		}
  	}
Signature · 1 line
kabe
#3 lore raw

PATCH v2 1/1 drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

Quoted 24 lines · On Thu, 10 May 2018 19:30:45 +0900 Taketo Kabe <[email protected]> wrote:
Signed-off-by Taketo Kabe <[email protected]>

---
diff -up ./drivers/net/wireless/broadcom/b43/dma.c.b43 ./drivers/net/wireless/broadcom/b43/dma.c

drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +3 -4
@@ -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,

drivers/net/wireless/broadcom/b43/dma.c void b43_dma_handle_txstatus(struct b43_ · line 1530

Quoted 10 lines
drivers/net/wireless/broadcom/b43/dma.c renamed from drivers/net/wireless/broadcom/b43/dma.c.b43 +4 -3
-				       "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 <[email protected]>

I think this is a good thing to have.
It improves robustness against firmware/DMA misbehavior.

Signature · 8 lines
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>
#4 lore raw

PATCH v2 1/1 drivers/net/wireless/broadcom/b43: fix transmit failure when VT is switched

In reply to Taketo Kabe
Quoted 3 lines · Taketo Kabe

From: Taketo Kabe <[email protected]>

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

Signature · 1 line
Kalle Valo
#5 lore raw

PATCH v2 1/1 b43: fix transmit failure when VT is switched

In reply to Taketo Kabe
Quoted 47 lines · kabe at sra-tohoku.co.jp

From: Taketo Kabe <[email protected]>

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.

Quoted 8 lines

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 <[email protected]>
Reviewed-by Michael Buesch <[email protected]>
[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.

Signature · 3 lines
https://patchwork.kernel.org/patch/10391617/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
#6 lore raw

Re: [v2] b43: fix transmit failure when VT is switched

In reply to Taketo Kabe
Quoted 47 lines · [email protected] wrote:

From: Taketo Kabe <[email protected]>

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.

Quoted 8 lines

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 <[email protected]>
Reviewed-by Michael Buesch <[email protected]>
[[email protected]: 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.

Signature · 3 lines
https://patchwork.kernel.org/patch/10391617/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#8 lore raw

PATCH v3 1/1 b43: fix transmit failure when VT is switched

From: Taketo Kabe <[email protected]>

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 <[email protected]>
Reviewed-by Michael Buesch <[email protected]>
---
 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 .

drivers/net/wireless/broadcom/b43/dma.c +7 -7
index 6837064..6b0e1ec 100644
@@ -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;
 		}
 	}
Signature · 1 line
kabe
#9 lore raw

PATCH v3 1/1 b43: fix transmit failure when VT is switched

Quoted 45 lines · kabe at sra-tohoku.co.jp

From: Taketo Kabe <[email protected]>

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.

Quoted 7 lines

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 <[email protected]>
Reviewed-by Michael Buesch <[email protected]>

Patch applied to wireless-drivers-next.git, thanks.

66cffd6daab7 b43: fix transmit failure when VT is switched

Signature · 3 lines
https://patchwork.kernel.org/patch/10396133/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
#10 lore raw

Re: [v3] b43: fix transmit failure when VT is switched

In reply to Taketo Kabe
Quoted 45 lines · [email protected] wrote:

From: Taketo Kabe <[email protected]>

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.

Quoted 7 lines

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 <[email protected]>
Reviewed-by Michael Buesch <[email protected]>

Patch applied to wireless-drivers-next.git, thanks.

66cffd6daab7 b43: fix transmit failure when VT is switched

Signature · 3 lines
https://patchwork.kernel.org/patch/10396133/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches