brcmfmac: high cpu utilization #37
Comments
|
I never witnessed such problem, do you see a very high interrupt activity in |
|
I wonder if using an initramfs (having brcmfmac module, but lacking nvram.txt ) ? At least in the process above, I wonder if rmmod modprobe is enough to recover the issue (as I don't see why moving nvram.txt on rmmod would change things ?)... |
|
I forgot to mention that wifi does not work at all without making |
|
Related dmesg entries:
(and that's it, no link shows up) |
|
The The WiFi driver should fall back to loading The - interrupt-parent = <&gpio>;
- interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "host-wake";What happens if you do the |
|
Well, without I think you are on the right track: I commented the lines you proposed out and the cpu load has decreased drastically. Thank you very much for that hint! But I wonder what side effects this change actually has, can you maybe clear up a bit what these interrupt specifications were made for originally? Yeah, reloading without changing anything does not solve that problem, the cpu-intensive process just shows up as before. |
|
Could you please try to take the The Bluetooth part of BCM chip shouldn't influence the WiFi. It should be a sign that something isn't correct with the WiFi part, the WiFi firmware binary is the main culprit. Could you please clarify what do you mean by One of functions of the |
|
First of all, thank you very much for the background information on the driver's interrupt specifications! I certainly would give your proposal a try, but I don't know which original firmware file to use, as there are three different ones to choose from. The bin files can be found here |
|
You should be able to download zip file with the original Android ROM from XDA forums or somewhere else, then you could extract the firmware files from it. The cl2n firmware isn't used by older chips, please ignore that message. Please try to re-check the Bluetooth gpios, maybe one of them is shared with the WiFi and device-tree isn't correct. The WiFi MMC card should be detected without Bluetooth. |
|
Actually all of the files found with the link are the ones included into the ROM, I know for sure because I have set up the android build system. Maybe I can give each of them a try whenever time is in great abundance to me.
So firmware is actually loaded successfully despite the error message?
I just double checked the gpios, and they are on par with the downstream kernel (well, as far as I could tell). When my "not working at all"-condition is reached, the MMC card is in fact detected, it's just the wifi interface (wlan0) that does not show up, that's why I am a bit puzzled about this problem… |
Correct
I would try to disable the Bluetooth part of the downstream kernel and check whether it has a working WiFi. This will tell us whether it should work without the Bluetooth in upstream. |
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line grate-driver#37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line grate-driver#37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Cc: Chen Li <[email protected]> WARNING: please, no spaces at the start of a line #37: FILE: mm/nommu.c:226: + return __vmalloc(size, GFP_KERNEL);$ total: 0 errors, 1 warnings, 16 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./patches/nommu-remove-__gfp_highmem-in-vmalloc-vzalloc.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Chen Li <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
In a memory pressure situation, I'm seeing the lockdep WARNING below. Actually, this is similar to a known false positive which is already addressed by commit 6dcde60 ("xfs: more lockdep whackamole with kmem_alloc*"). This warning still persists because it's not from kmalloc() itself but from an allocation for kmemleak object. While kmalloc() itself suppress the warning with __GFP_NOLOCKDEP, gfp_kmemleak_mask() is dropping the flag for the kmemleak's allocation. Allow __GFP_NOLOCKDEP to be passed to kmemleak's allocation, so that the warning for it is also suppressed. ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc7-BTRFS-ZNS+ #37 Not tainted ------------------------------------------------------ kswapd0/288 is trying to acquire lock: ffff88825ab45df0 (&xfs_nondir_ilock_class){++++}-{3:3}, at: xfs_ilock+0x8a/0x250 but task is already holding lock: ffffffff848cc1e0 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x112/0x160 kmem_cache_alloc+0x48/0x400 create_object.isra.0+0x42/0xb10 kmemleak_alloc+0x48/0x80 __kmalloc+0x228/0x440 kmem_alloc+0xd3/0x2b0 kmem_alloc_large+0x5a/0x1c0 xfs_attr_copy_value+0x112/0x190 xfs_attr_shortform_getvalue+0x1fc/0x300 xfs_attr_get_ilocked+0x125/0x170 xfs_attr_get+0x329/0x450 xfs_get_acl+0x18d/0x430 get_acl.part.0+0xb6/0x1e0 posix_acl_xattr_get+0x13a/0x230 vfs_getxattr+0x21d/0x270 getxattr+0x126/0x310 __x64_sys_fgetxattr+0x1a6/0x2a0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&xfs_nondir_ilock_class){++++}-{3:3}: __lock_acquire+0x2c0f/0x5a00 lock_acquire+0x1a1/0x4b0 down_read_nested+0x50/0x90 xfs_ilock+0x8a/0x250 xfs_can_free_eofblocks+0x34f/0x570 xfs_inactive+0x411/0x520 xfs_fs_destroy_inode+0x2c8/0x710 destroy_inode+0xc5/0x1a0 evict+0x444/0x620 dispose_list+0xfe/0x1c0 prune_icache_sb+0xdc/0x160 super_cache_scan+0x31e/0x510 do_shrink_slab+0x337/0x8e0 shrink_slab+0x362/0x5c0 shrink_node+0x7a7/0x1a40 balance_pgdat+0x64e/0xfe0 kswapd+0x590/0xa80 kthread+0x38c/0x460 ret_from_fork+0x22/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&xfs_nondir_ilock_class); lock(fs_reclaim); lock(&xfs_nondir_ilock_class); *** DEADLOCK *** 3 locks held by kswapd0/288: #0: ffffffff848cc1e0 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 #1: ffffffff848a08d8 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x269/0x5c0 #2: ffff8881a7a820e8 (&type->s_umount_key#60){++++}-{3:3}, at: super_cache_scan+0x5a/0x510 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Naohiro Aota <[email protected]> Acked-by: Catalin Marinas <[email protected]> Cc: "Darrick J . Wong" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
|
I remove cap-sdio-irq in dts and fix |
I followed the suggestion to check, and found that we didn't connect the WL-HOST-WAKE pin to CPU in my test board, |
With
bcm4330, processes likekworker/u8:2-brcmf_wq/mmc1:0001:1keep cpu utilization high – slowing down its normal operation and killing the battery. I found a very much quick and dirty workaround that I don't quite understand myself:I make
nvram.txtinaccessible to the driver. Right after boot a script wouldrmmodthe brcmfmac module. Then, after moving thenvram.txtback in place, the driver is loaded, i.einsmodded again, making wifi work without cpu utilization issues. Any ideas what is going on?The text was updated successfully, but these errors were encountered: