Taketo Kabe 66cffd6daa b43: fix transmit failure when VT is switched ... 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> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>		2018-05-15 08:40:06 +03:00
..
b43.h
bus.c
bus.h
debugfs.c
debugfs.h
dma.c	b43: fix transmit failure when VT is switched	2018-05-15 08:40:06 +03:00
dma.h
Kconfig
leds.c
leds.h
lo.c
lo.h
main.c
main.h
Makefile
phy_a.h
phy_ac.c
phy_ac.h
phy_common.c
phy_common.h
phy_g.c
phy_g.h
phy_ht.c
phy_ht.h
phy_lcn.c
phy_lcn.h
phy_lp.c
phy_lp.h
phy_n.c	b43: Replace mdelay with usleep_range in b43_radio_2057_init_post	2018-01-11 21:54:01 +02:00
phy_n.h
pio.c
pio.h
ppr.c
ppr.h
radio_2055.c
radio_2055.h
radio_2056.c
radio_2056.h
radio_2057.c
radio_2057.h
radio_2059.c
radio_2059.h
rfkill.c
rfkill.h
sdio.c
sdio.h
sysfs.c
sysfs.h
tables.c
tables.h
tables_lpphy.c
tables_lpphy.h
tables_nphy.c
tables_nphy.h
tables_phy_ht.c
tables_phy_ht.h
tables_phy_lcn.c
tables_phy_lcn.h
wa.c
wa.h
xmit.c
xmit.h