After upgrade to Kubuntu 12.10 bluetooth status is incorrect and works only after service bluetooth stop / start cylce

Bug #1072118 reported by jhoechtl
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I have upgraded to Kubuntu 12.10 Quantal Quetzal from 12.04 through dist-upgrade. After the upgrade, on a fresh boot, bluetooth will only work after a

service bluetooth stop
service bluetooth start

cylcle.

Other effects witrhout the cycle are eg. the KDE bluez applet will not show bluetooth disabled after clicking disable. Trying to pair with my mobile always brings the error message "Device busy".
---
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
DistroRelease: Ubuntu 12.10
InstallationDate: Installed on 2012-04-28 (182 days ago)
InstallationMedia: Kubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120424)
InterestingModules: bnep rfcomm btusb bluetooth
MachineType: Dell Inc. Latitude E6410
MarkForUpload: True
Package: bluez 4.101-0ubuntu6
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-18-generic root=UUID=8979697f-3f64-4931-aeaf-55d85023aa81 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Tags: quantal
Uname: Linux 3.5.0-18-generic x86_64
UpgradeStatus: Upgraded to quantal on 2012-10-18 (8 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 08/23/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A10
dmi.board.name: 0667CC
dmi.board.vendor: Dell Inc.
dmi.board.version: A03
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA10:bd08/23/2011:svnDellInc.:pnLatitudeE6410:pvr0001:rvnDellInc.:rn0667CC:rvrA03:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6410
dmi.product.version: 0001
dmi.sys.vendor: Dell Inc.
hciconfig:
 hci0: Type: BR/EDR Bus: USB
  BD Address: 1C:65:9D:AB:4D:07 ACL MTU: 1021:8 SCO MTU: 64:1
  UP RUNNING PSCAN ISCAN
  RX bytes:3953 acl:27 sco:0 events:77 errors:0
  TX bytes:1541 acl:26 sco:0 commands:50 errors:0

Revision history for this message
jhoechtl (johann-hoechtl) wrote : BootDmesg.txt

apport information

tags: added: apport-collected quantal
description: updated
Revision history for this message
jhoechtl (johann-hoechtl) wrote : CurrentDmesg.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : Dependencies.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : Lspci.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : Lsusb.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : ProcInterrupts.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : ProcModules.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : UdevDb.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : UdevLog.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : getfacl.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : rfkill.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote : syslog.txt

apport information

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

The underlying problems seems to be:

The described behaviour is only visible, when shutting down with bluetooth disabled.
If I leave bluetooth enabled, bluetooth works when rebooting. It seems as the initial state of bluetooth is not correctly determined on startup or applet initialisation, which may be due to the me also affecting bug #1068436

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bluez (Ubuntu):
status: New → Confirmed
Revision history for this message
Tshering Namgyal Wangdi (drwangdi) wrote :

"service bluetooth start/stop" command only works in sudo mode in kubuntu 12.10 quantal 64 bit.

System - Dell Inspiron N5050
Processor Intel Pentium(R) CPU B960 @ 2.2 GHz
2 Gb RAM

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

My fear is that the bug I reported is also related to
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/277211

which complicates things a lot.

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

After some more investigations I can come up with this consistent behaviour:

If I reboot the laptop of with bluetooth enabled, it will come up the next time working. Working means the status is correctly recognized by the Kubuntu applet and bluetooth is working.

If I disable Bluetooth, the hardware display on the laptop remains lit. In Kubuntu 12.04, the display went off. However, the device is properly unpowered, as it saves 4 Watts (checked with meter). After reboot, the state is correctly remembered, that means the device is unpowered (the hardware indication is still lit btw.) However, the bluetooth icon in panel will recognize the adapter as powered. Unpowering has no effect and doesn't work: If I choose unpower in the applet, simply nothing happens, it remains thinking it is still powered, while it is unpowered. In other words, there is not way to power bluetooth with the applet.

service bluetooth stop
service bluetooth start

will not bring bluetooth back ... it will remain unpowered and the applet thinking it is powered.

However, issuing

sudo hciconfig hci0 reset

WILL power bluetooth AND the applet back working, so that it can be powered / unpowered.

So I think the bluetoothd stack doesn't recognize the unpowered adapter, yet correctly remains it unpowered (state keeps preserved).

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

However, if I unpower the device using the Kubuntu applet (it's relaibly not working, draining 5 Watts less)

/etc/init/rfkill-store

will save the state as enabled

/var/rfkill/saved-state

contains

hci0 0

after a boot. So it seems the device remembers it's last state and not bluetoothd. With the hardware lit always on, I suspect it is a hardware issue with my adapter rather than an error with upstart or bluetoothd.

Revision history for this message
Øyvind Stegard (oyvindstegard) wrote :

Bluetooth acting strangely here, in Ubuntu 12.10. Led is always on, no matter if I disable or enable bluetooth via applet, however syslog tells me the device is enabled/disabled and the rfkill softblock state is altered. The hardware bluetooth led worked fine in Ubuntu 12.04.

I am unable to use Bluetooth without first fiddling with stop/start bluetooth service or doing device resets with hciconfig or enable/disable with applet, rmmod btusb; modprobe btusb reset=1, etc. Rather messy..

Bus 002 Device 003: ID 413c:8187 Dell Computer Corp. DW375 Bluetooth Module

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

Is this a bluez bug or a kernel bug? As it seems at least tighlty related to
 ID 413c:8187 Dell Computer Corp. DW375 Bluetooth Module

I would guess it's a kernel issue. It's still present in 3.7. btw. (tried upstream mainline)

Revision history for this message
jhoechtl (johann-hoechtl) wrote :

With Linux ubuntu 3.8.0-9-generic #18-Ubuntu SMP Thu Feb 28 17:02:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux nothing has changed.

However, this behaviour is also interesting:

After hibernate and resume, the status is correct, and enabling / disabling using bluez works. After a second hibernate / resume cycle, the whole adapter is gone,

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.