Bug 1596733 - activating b43 wireless module freezes the mouse/trackpad
Summary: activating b43 wireless module freezes the mouse/trackpad
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-06-29 14:52 UTC by Paul Kuin
Modified: 2018-11-19 21:26 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-11-19 21:26:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
lsusb (533 bytes, text/plain)
2018-07-02 20:57 UTC, Paul Kuin
no flags Details
lspci -nn (2.80 KB, text/plain)
2018-07-02 20:58 UTC, Paul Kuin
no flags Details
/proc/interrupts (1.88 KB, text/plain)
2018-07-02 20:59 UTC, Paul Kuin
no flags Details
modprobe -rv b43 output (76 bytes, text/plain)
2018-07-02 22:23 UTC, Paul Kuin
no flags Details
output from modprobe -v b43 btcoex=0 (510 bytes, text/plain)
2018-07-02 22:24 UTC, Paul Kuin
no flags Details

Description Paul Kuin 2018-06-29 14:52:03 UTC
Description of problem:

HP6735s laptop; AMD  broadcom 4312 wireless 
Installed fresh Fedora 28-1.1 x86-64 from live DVD on 2018-06-28
The wireless driver was not loaded, so I used wired internet to get and install b43-fwcutter which worked; I could get the wireless up. 
However, the mouse and wireless show interference. Network errors are reported by gmail when moving the mouse, and when there is more internet traffic, like going to the guardian.co.uk site, the mouse freezes completely. 
I notice the broadcom us on usb3-3 (fast) and the mouse on usb 3-6 (slow) which means perhaps something ?

It looks like they are using the same communication channel. 

Using an old live disk from Knoppix with Debian [ i.e., Linux version 4.2.6-64 (root@eeepc) (gcc version 5.2.1 20151010 (Debian 5.2.1-22) ] there is no problem. However, I do not see where the difference is, and these days I do not know how to force irq's etc. 

I need help to fix the configuration.


Version-Release number of selected component (if applicable):

Fedora 28-1.1

How reproducible:

I can reproduce it on the system described very briefly above. 

Steps to Reproduce:
1. modprobe -a b43
2. firefox http://guardian.co.uk
3. this should result in a frozen mouse 

Actual results:

frozen mouse and trackpad 

Expected results:

no interference between b43 and mouse

Additional info:

This is my first bug for Fedora

Comment 1 Larry Finger 2018-07-02 17:25:00 UTC
Driver b43 handles PCIe devices. What are you seeing as a Broadcom device on a USB port?

Please post the output of 'lsusb', 'lspci -nn'. and 'cat /proc/interrupts'.

Larry

Comment 2 Paul Kuin 2018-07-02 20:57:15 UTC
Created attachment 1456036 [details]
lsusb

as requested

Comment 3 Paul Kuin 2018-07-02 20:58:08 UTC
Created attachment 1456060 [details]
lspci -nn

as requested

Comment 4 Paul Kuin 2018-07-02 20:59:15 UTC
Created attachment 1456062 [details]
/proc/interrupts

as requested

Comment 5 Larry Finger 2018-07-02 21:27:27 UTC
The Broadcom USB device is a BCM2045 Bluetooth interface. Does your mouse use BT?

Please run the following commands and post the output:

sudo modprobe -rv b43
sudo modprobe -v b43 btcoex=0

Does the second command, with Bluetooth coexistence turned off, help?

Comment 6 Paul Kuin 2018-07-02 22:23:05 UTC
Created attachment 1456076 [details]
modprobe -rv b43 output

Hi Larry,
 
I did the modprobe, here the first output. 

I am not using BT - this is a laptop, so I'm using the trackpad now. I was also using a mouse, but that just complicates matters. 

After the second command I put up the browser with guardian.co.uk and it froze when I tried to add the gmail in a second tab. Could not abort that, so killed the system (I keep switching to a live disk to email the files). 

Thanks so far.

Comment 7 Paul Kuin 2018-07-02 22:24:28 UTC
Created attachment 1456077 [details]
output from modprobe -v  b43 btcoex=0

Here is the output from the second modprobe command.

Comment 8 Larry Finger 2018-07-04 17:11:37 UTC
Comment on attachment 1456077 [details]
output from modprobe -v  b43 btcoex=0

Is there a reason that you are forcing software encryption? That should only be needed when there is a hardware problem.

I am also curious about the qos=0. Is there a reason for that parameter?

Comment 9 Larry Finger 2018-07-04 17:14:49 UTC
Actually, forcing the CPU to do software encryption could keep it busy enough to miss low-priority interrupts. Try it without the "nohwcrypt=1" option. You do not need the btcoex option.

Comment 10 Laura Abbott 2018-10-01 21:24:14 UTC
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 28 kernel bugs.
 
Fedora 28 has now been rebased to 4.18.10-300.fc28.  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 29, and are still experiencing this issue, please change the version to Fedora 29.
 
If you experience different issues, please open a new bug report for those.

Comment 11 Paul Kuin 2018-11-19 12:59:02 UTC
This has been fixed in the latest release.

Comment 12 Jeremy Cline 2018-11-19 21:26:34 UTC
Thanks for letting us know


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