Bug 1061836 - regression BCM4331 wireless, b43-phy0 ERROR PHY transmission error [NEEDINFO]
Summary: regression BCM4331 wireless, b43-phy0 ERROR PHY transmission error
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-wireless-b43
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-05 17:50 UTC by Chris Murphy
Modified: 2015-11-23 17:22 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-23 17:22:50 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 70031 0 None None None Never

Description Chris Murphy 2014-02-05 17:50:53 UTC
Description of problem:
Since 3.14.0-0.rc1.git0.1 (non-debug) wireless connections start OK, rapidly degrade in performance to the point there's no throughput, and programs just hang or give up. Many kernel messages "b43-phy0 ERROR: PHY transmission error" occur at the same time.

Version-Release number of selected component (if applicable):
3.14.0-0.rc1.git0.2.fc21.x86_64

How reproducible:
Always with 3.14 kernels

Steps to Reproduce:
1. Boot and use wireless.

Actual results:
[  112.702339] b43-phy0 ERROR: PHY transmission error
[  171.473736] ------------[ cut here ]------------
[  171.473744] WARNING: CPU: 0 PID: 116 at lib/dma-debug.c:491 add_dma_entry+0x127/0x130()
[  171.473745] DMA-API: exceeded 7 overlapping mappings of pfn 2537ac
[  171.473746] Modules linked in: fuse ccm ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw arc4 b43 mac80211 cfg80211 ssb iTCO_wdt iTCO_vendor_support applesmc input_polldev nls_utf8 hfsplus uvcvideo x86_pkg_temp_thermal videobuf2_vmalloc videobuf2_memops coretemp btusb kvm_intel hid_appleir kvm crct10dif_pclmul bluetooth videobuf2_core crc32_pclmul videodev crc32c_intel ghash_clmulni_intel 6lowpan_iphc rfkill media bcm5974 microcode i2c_i801 sdhci_pci tg3 ptp sdhci mmc_core snd_hda_codec_cirrus
[  171.473784]  pps_core snd_hda_codec_generic sbs snd_hda_codec_hdmi snd_hda_intel snd_hda_codec sbshc snd_hwdep snd_seq apple_gmux snd_seq_device snd_pcm apple_bl bcma snd_timer snd mei_me soundcore mei lpc_ich shpchp mfd_core nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c xor raid6_pq radeon i915 i2c_algo_bit firewire_ohci drm_kms_helper ttm firewire_core drm crc_itu_t i2c_core video
[  171.473812] CPU: 0 PID: 116 Comm: kworker/u16:4 Not tainted 3.14.0-0.rc1.git0.2.fc21.x86_64 #1
[  171.473813] Hardware name: Apple Inc. MacBookPro8,2/Mac-94245A3940C91C80, BIOS    MBP81.88Z.0047.B27.1201241646 01/24/12
[  171.473818] Workqueue: phy0 b43_tx_work [b43]
[  171.473820]  0000000000000000 000000003585fa80 ffff88025ff8fb48 ffffffff817cef2d
[  171.473823]  ffff88025ff8fb90 ffff88025ff8fb80 ffffffff810967cd 00000000002537ac
[  171.473826]  ffff8802605819c0 0000000000000292 ffffffff82d7e340 0000000000000292
[  171.473828] Call Trace:
[  171.473832]  [<ffffffff817cef2d>] dump_stack+0x4d/0x66
[  171.473835]  [<ffffffff810967cd>] warn_slowpath_common+0x7d/0xa0
[  171.473837]  [<ffffffff8109684c>] warn_slowpath_fmt+0x5c/0x80
[  171.473839]  [<ffffffff813f353d>] ? active_pfn_read_overlap+0x2d/0x50
[  171.473841]  [<ffffffff813f3b07>] add_dma_entry+0x127/0x130
[  171.473843]  [<ffffffff813f3e6a>] debug_dma_map_page+0x11a/0x140
[  171.473850]  [<ffffffffa08421f2>] b43_dma_tx+0x2a2/0xbf0 [b43]
[  171.473856]  [<ffffffffa08136f2>] b43_tx_work+0xa2/0x130 [b43]
[  171.473859]  [<ffffffff810bba80>] process_one_work+0x220/0x6f0
[  171.473861]  [<ffffffff810bba14>] ? process_one_work+0x1b4/0x6f0
[  171.473866]  [<ffffffff810bc06b>] worker_thread+0x11b/0x3a0
[  171.473868]  [<ffffffff810bbf50>] ? process_one_work+0x6f0/0x6f0
[  171.473871]  [<ffffffff810c43cf>] kthread+0xff/0x120
[  171.473873]  [<ffffffff810c42d0>] ? insert_kthread_work+0x80/0x80
[  171.473876]  [<ffffffff817e2cfc>] ret_from_fork+0x7c/0xb0
[  171.473878]  [<ffffffff810c42d0>] ? insert_kthread_work+0x80/0x80
[  171.473879] ---[ end trace 35c2b50962922df9 ]---
[  171.518691] b43-phy0 ERROR: PHY transmission error

Expected results:

For wireless to continue working.

Additional info:

Regression testing shows the problem doesn't occur with kernels:
3.11.10-301.fc20.x86_64
3.12.9-301.fc20.x86_64
3.13.0-1.fc21.x86_64

Configuration:
Apple MacBookPro 8,2 (2011)
03:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev 02)

Wireless access point:
Linksys WRT600N v1.1
DD-WRT v24-sp2 (07/24/13) mini-usb-ftp - build 22118 
Linux 2.4.37 #32206 Wed Jul 24 02:20:18 CEST 2013 mips

Comment 1 Larry Finger 2014-02-05 18:05:54 UTC
Mostly copied from the bugzilla.kernel.org entry.

Thanks for the complete posting.

I do not have a 14e4:4331 device, but I have posted on the wireless and b43 mailing lists to see if anyone else has seen the problem. My 1434:4315 does not have this problem, which is a an indication that changes in the rest of the kernel did not cause this problem. One difficulty is that I do not understand the "PHY transmission error" messages. They are some kind of error indication from the firmware that the TX descriptor is faulty, but the cause is not clear. A further complication is that we have no source for that firmware.

I reviewed the changes to both bcma and b43 between 3.13 and 3.14-rc1. None of the bcma changes is likely to be the problem. The only change for b43 that cannot be ruled out is one that fixed a definite bug. It is possible, however, that fixing that bug exposed another that is now triggering on your device.

Is it possible for you to obtain the full mainline git repo and bisect the problem? If that is not possible, perhaps the Fedora devs could build a special kernel with commit 64e5acb reverted. That kernel would test the one commit that I question.

Comment 2 lnxslck 2014-07-25 18:13:21 UTC
I'm also facing this problem, i have a Macbook from 2007 and have Fedora 20 x86_64 with kernel 3.15.6-200.fc20.x86_64.

After installing the firmware the wireless interface is up but it doesn't scan for wireless networks, therefore it's useless. all i see in the messages are:

[  692.143318] b43-phy1 warning: LEDs: Unknown behaviour 0x5B
[  692.143321] b43-phy1 warning: LEDs: Unknown behaviour 0x5B
[  692.143323] b43-phy1 warning: LEDs: Unknown behaviour 0x46
[  692.143324] b43-phy1 warning: LEDs: Unknown behaviour 0x3B
[  692.312094] b43-phy1: Loading firmware version 666.2 (2011-02-23 01:15:07)
[  692.317155] b43-phy1 ERROR: radio post init timeout
[  692.360190] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

Comment 3 Jaroslav Reznik 2015-03-03 15:27:13 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 4 Justin M. Forbes 2015-10-20 19:38:51 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.

Comment 5 Fedora Kernel Team 2015-11-23 17:22:50 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.