Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1361867 - Bluetooth BCM2046 Not Working In F23, F24
Summary: Bluetooth BCM2046 Not Working In F23, F24
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Don Zickus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-31 11:32 UTC by Randall "Randy" Berry
Modified: 2018-05-29 11:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 11:50:40 UTC


Attachments (Terms of Use)
fpaste --sysinfo (deleted)
2016-07-31 11:32 UTC, Randall "Randy" Berry
no flags Details
lsusb -t (deleted)
2016-08-01 23:45 UTC, Randall "Randy" Berry
no flags Details
dmesg (deleted)
2016-08-01 23:47 UTC, Randall "Randy" Berry
no flags Details
lsusb -v (deleted)
2016-08-02 14:48 UTC, Randall "Randy" Berry
no flags Details

Description Randall "Randy" Berry 2016-07-31 11:32:19 UTC
Created attachment 1186034 [details]
fpaste --sysinfo

Description of problem:
Bluetooth BCM2046 not working. Device not detected at all. It works fine in F22 but not in F23 or F24. The USB Hub attached to the device is detected, but no Bluetooth device its self.

Version-Release number of selected component (if applicable):
bluez-5.40-2.fc24.x86_64

How reproducible:
Device not detected at boot

Actual results:
Bluetooth managers crash.

Expected results:
Bluetooth should be detected and work properly.

Additional info:
See attachment for complete --sysinfo

Please reassign if bluez is not the culprit.

Comment 1 Don Zickus 2016-08-01 14:47:22 UTC
Hi Randy,

Can you provide the output of 'lsusb -t'. I want to see if the bt drivers attached to your bt device.  Also the output of 'dmesg' would be helpful to see what the bt stack is doing in the kernel.

Can you also explain 'Bluetooth managers crash'?  Do you have a dump or journalctl entry of this?

Cheers,
Don

Comment 2 Randall "Randy" Berry 2016-08-01 23:45:17 UTC
Created attachment 1186571 [details]
lsusb -t

Comment 3 Randall "Randy" Berry 2016-08-01 23:47:04 UTC
Created attachment 1186572 [details]
dmesg

Comment 4 Randall "Randy" Berry 2016-08-01 23:50:43 UTC
(In reply to Don Zickus from comment #1)
> Hi Randy,
> 
> Can you provide the output of 'lsusb -t'. I want to see if the bt drivers
> attached to your bt device.  Also the output of 'dmesg' would be helpful to
> see what the bt stack is doing in the kernel.

Attachments created. 
> 
> Can you also explain 'Bluetooth managers crash'?  Do you have a dump or
> journalctl entry of this?


I just get the dialog that bluez is not running, blueman-manager cannot continue.

Comment 5 Don Zickus 2016-08-02 14:09:17 UTC
Hi Randy,

For some reason it is not showing up in the dmesg log nor the lsusb -t output.

I am guessing if you run 'lsmod |grep bluetooth' nothing will show up.  Can you attach the output of 'lsusb -v'.  I want to see how this device is showing up to the system.

I am thinking this is a kernel issue, but I am trying to figure out what broke.  You said this used to work on f22.  What kernel version was that?

Cheers,
Don

Comment 6 Randall "Randy" Berry 2016-08-02 14:48:47 UTC
Created attachment 1186857 [details]
lsusb -v

Comment 7 Randall "Randy" Berry 2016-08-02 14:58:47 UTC
(In reply to Don Zickus from comment #5)
> Hi Randy,
> 
> For some reason it is not showing up in the dmesg log nor the lsusb -t
> output.
> 
> I am guessing if you run 'lsmod |grep bluetooth' nothing will show up.  Can
> you attach the output of 'lsusb -v'.  I want to see how this device is
> showing up to the system.
> 
> I am thinking this is a kernel issue, but I am trying to figure out what
> broke.  You said this used to work on f22.  What kernel version was that?
> 
> Cheers,
> Don

Correct, nothing shows up under lsmod.

Without having F22 kernel available to me at the moment I checked koji and came up with 4.4.13-200.fc22, that sounds about right for the version I was running. 

I used to see the BT getting loaded in F22, but I switched to an SSD for F24 and it's just too fast so I don't see any errors or anything in the boot up noise.

Comment 8 Don Zickus 2016-08-02 16:03:40 UTC
Hi Randy,

Thanks for the info.  I see the broadcom chip but it doesn't expose the bluetooth device for some reason.  This is the tricky part with broadcom and marvel chips, you have to load their drivers first and then they expose the virtual bluetooth devices.  For some reason their driver is not exposing the device correctly and I am not sure what to expect.

Do you mind installing a 4.4.0-1.f24 kernel for me and seeing if the bluetooth driver loads?  If so, attach the dmesg and lsusb -v output.

This kernel should not cause any problems with your system (hopefully the ssd loads correctly, but 4.4 should be new enough..)

http://koji.fedoraproject.org/koji/buildinfo?buildID=710494

Cheers,
Don

Comment 9 Randall "Randy" Berry 2016-08-02 17:14:50 UTC
dnf won't let me do it. I downloaded the kernel, kernel-core, kernel-modules, and kernel-modules-extra files, changed to the download directory and tried several ways including dnf install|downgrade --allowerasing --nogpgcheck kernel*.rpm and it still won't allow it. "Error: conflicting requests."

rpm -i kernel*.rpm just spits out "package kernel-4.6.5-300.fc24.x86_64 (which is newer than kernel-4.4.0-1.fc24.x86_64) is already installed" etc..

I don't really want to replace anything if I don't have to, only install along side what I already have. I don't mind replacing the 4.5.7 kernel, but the other two (4.6.4 and 4.6.5) may still provide some use if something else refuses to work. BT may not work on the current kernel but at least that's the only thing I have found so far. lol

Any suggestions?

Comment 10 Don Zickus 2016-08-02 18:52:14 UTC
Hi Randy,

Hmm, that's annoying.  Can you try 'rpm -ivh --oldpackage kernel...'?  This
should not delete any kernel rpm (that is a yum/dnf config option, not rpm).

And technically all this is installing is just a /lib/modules directory, bunch of
files in /boot and an updated /etc/grub2.cfg file.  So it should be completely
on the side (assuming you have enough space in /boot).

Sorry for the problems.  I am also trying to get a Dell Latitude laptop from
our onsite Dell person to see if I can duplicate this.

Cheers,
Don

Comment 11 Randall "Randy" Berry 2016-08-02 22:01:30 UTC
Thanks for your time Don, but no dice. I tried the 4.4.0 kernel and BT is still not even detected. Nothing any different in lsusb and the bluez daemon still is not running. I didn't try much else. Anything else you'd like me to try before I write off the kernel and let dnf remove the old 4.4.0 version?

Comment 12 Don Zickus 2016-08-03 14:08:01 UTC
Hi Randy,

Thanks for you effort.  The last thing I wanted you to do before removing the kernel is a simple 'dmesg|grep -i bluetooth' and 'dmesg|grep -i bcm'.  I expect the bluetooth grep to be empty and the bcm grep to contain simple one line descriptions.  If they are more verbose than that there might be something useful in there.  Otherwise feel free to delete the kernel.

I am still scratching my head how the f22 kernel worked.  Again I am pretty sure the problem is a kernel driver not setting up the broadcom device correctly.  As a result, the psuedo bluetooth doesn't show up and btusb driver doesn't load.  

If we can resolve all that and get the btusb driver to load, then I expect the bluetooth daemon and friends to just work correctly.

I need to find a machine over here that has a broadcom chip to understand how it is _supposed_ to work.  Intel's bt/wifi chips just show devices with no magic which is the chips I have been using for some recent bluetooth testing.

Sorry for the lack of positive feedback.

Cheers,
Don

Comment 13 Randall "Randy" Berry 2016-08-04 20:39:02 UTC
The bluetooth query is empty, the bcm query only contains one line:
"[    1.553269] usb 3-1: Product: BCM2046B1"

Oh well, I guess I'm SOL. Thanks again for looking in to it so deeply.

Comment 14 Don Zickus 2016-08-05 01:56:32 UTC
Hi,

I just read, this device is special.  Can you install the bluez-hid2hci package and reboot.

Supposedly that might help set the chip into the correct mode to be used properly.
https://bbs.archlinux.org/viewtopic.php?id=130995

Is a link to someone doing something similar.

Cheers,
Don

Comment 15 Randall "Randy" Berry 2016-08-05 06:16:32 UTC
Well, that works partially, I can see the card now and blueman loads but it won't find anything when searching for nearby devices.

$ lsusb|grep -i bluetooth
Bus 003 Device 005: ID 413c:8156 Dell Computer Corp. Wireless 370 Bluetooth Mini-card
Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

$ dmesg|grep -i bluetooth
[   19.383257] usb 3-1.3: Product: Dell Wireless 370 Bluetooth Mini-card
[   19.973827] Bluetooth: Core ver 2.21
[   19.973862] Bluetooth: HCI device and connection manager initialized
[   19.974635] Bluetooth: HCI socket layer initialized
[   19.974642] Bluetooth: L2CAP socket layer initialized
[   19.974661] Bluetooth: SCO socket layer initialized
[   20.852107] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   20.852112] Bluetooth: BNEP filters: protocol multicast
[   20.852119] Bluetooth: BNEP socket layer initialized
[   34.753869] Bluetooth: RFCOMM TTY layer initialized
[   34.753879] Bluetooth: RFCOMM socket layer initialized
[   34.753972] Bluetooth: RFCOMM ver 1.11

$ rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
1: dell-wifi: Wireless LAN
	Soft blocked: no
	Hard blocked: no
2: dell-bluetooth: Bluetooth
	Soft blocked: no
	Hard blocked: no
3: dell-wwan: Wireless WAN
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Comment 16 Don Zickus 2016-08-05 14:31:53 UTC
Hi Randy,

That is good news.  Now that we have the hardware discovered and the driver loaded,
we can focus on the userspace things.

Let's start with this, does running 'hciconfig'
show 'hci0' and if it does, is it 'UP' and 'RUNNING'?

'hciconfig hci0 up' will enable it and start it up.

Cheers,
Don

Comment 17 Randall "Randy" Berry 2016-08-05 20:11:03 UTC
It's up, still not finding new devices though.


$ hciconfig
hci0:	Type: BR/EDR  Bus: USB
	BD Address: 90:4C:E5:F8:E3:2A  ACL MTU: 1021:8  SCO MTU: 64:8
	UP RUNNING 
	RX bytes:664 acl:0 sco:0 events:49 errors:0
	TX bytes:3362 acl:0 sco:0 commands:48 errors:0

Comment 18 Don Zickus 2016-08-05 20:29:58 UTC
Hi Randy,

Hmm, does 

bluetoothctl

<wait 60 seconds>


show any devices you recognize?
(no need to paste that data here)

Cheers,
Don

Comment 19 Randall "Randy" Berry 2016-08-06 04:32:54 UTC
Nope nothing.. Other than the controller itself.

Comment 20 Don Zickus 2016-08-08 13:32:05 UTC
Hi Randy,

My scripts filtered out the main commands from my comment :-/

I meant to ask you to do:

bluetoothctl
#scan on
<wait 60 seconds>
#scan off
#devices
#quit

And see if devices listed anything other than your controller.

Sorry about that.

Cheers,
Don

Comment 21 Randall "Randy" Berry 2016-08-08 14:09:00 UTC
(In reply to Don Zickus from comment #20)
> Hi Randy,
> 
> My scripts filtered out the main commands from my comment :-/
> 
> I meant to ask you to do:
> 
> bluetoothctl
> #scan on
> <wait 60 seconds>
> #scan off
> #devices
> #quit

Yeah, that's what I figured you meant, so that's what I tried. Still no devices. It just dumps me to an empty prompt when I enter devices.

All this for a silly mouse to free up a usb port so I can fill it with another SDR.. I already run 2 SDRs simultaneously most of the time and a scanner... lol. (The scanner doesn't do the HF bands.) I'm a ham radio geek as you probably figured out.

Comment 22 Don Zickus 2016-08-08 15:17:13 UTC
Hi Randy,

Odd that it can't find your mouse.  I am not familiar with the broadcom device
at least the piece you have to flip modes (hid2hci).  That might be causing
something, as scanning should find it (I assume the mouse works fine???).

I am still trying to dig up a similiar device over here with no luck. :-/

I take it a usb hub won't give you a mouse and another SDR? :-)

Cheers,
Don

Comment 23 Randall "Randy" Berry 2016-08-08 16:22:33 UTC
I've not tried a hub. I don't know if a unpowered hub will work with these things. It would certainly have to be a powered hub. These things get pretty warm so I'm assuming they draw a little current.

I'd mail you my card, to fool with but I don't have any anti-static bags to ship it in. I don't trust shipping it alone in a bubble pack. Only God knows how much static can build up in one of those things. I know they are a dime a dozen on eBay, that's where I got mine. For about $6 plus free shipping. (US Seller/Shipping) (If you wanted to go that far) I looked for an Intel version but no luck they are all Broadcom.

It just puzzles me why did it work in F22 but not F23 or F24? I've tried the latest updates to the bluez lineup of packages too. Still no luck. Time to look at koji and see if I can find old bluez packages for F22 and perhaps build them for F24 I guess. I can see if that's the problem but at this rate I somehow doubt it.

Meanwhile I guess I'll invest in a powered hub.

Comment 24 Fedora End Of Life 2017-02-28 10:02:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 25 Fedora End Of Life 2018-05-03 08:37:44 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 26 Fedora End Of Life 2018-05-29 11:50:40 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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