toshiba_bluetooth re-enables every 5 secs even though BlueTooth is set to off in the Ubuntu BT menu Icon

[porg]

In Ubuntu 10.10's BlueTooth menu icon I set it to "off" on my Toshiba Tecra M3
but nevertheless the following message occurs in /var/log/syslog every 5 seconds:

Apr 4 17:51:04 sn-toshiba kernel: [13228.040604] toshiba_bluetooth: Re-enabling Toshiba Bluetooth
Apr 4 17:51:09 sn-toshiba kernel: [13233.029133] toshiba_bluetooth: Re-enabling Toshiba Bluetooth
Apr 4 17:51:14 sn-toshiba kernel: [13238.040217] toshiba_bluetooth: Re-enabling Toshiba Bluetooth

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-28-generic 2.6.35-28.49
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-28.49-generic 2.6.35.11
Uname: Linux 2.6.35-28-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: sn 1541 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'ICH6'/'Intel ICH6 with AD1981B at irq 17'
   Mixer name : 'Analog Devices AD1981B'
   Components : 'AC97a:41445374'
   Controls : 28
   Simple ctrls : 20
Date: Mon Apr 4 17:49:17 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: TOSHIBA TECRA M3
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-28-generic root=UUID=b180fb66-71f4-436d-88dd-cf89682ae015 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.38.5
SourcePackage: linux
dmi.bios.date: 11/15/2005
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.40
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion1.40:bd11/15/2005:svnTOSHIBA:pnTECRAM3:pvrPTM30E-0CQ01TGR:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: TECRA M3
dmi.product.version: PTM30E-0CQ01TGR
dmi.sys.vendor: TOSHIBA

[steubens (steubens)]

this was affecting the heat in his machine, as the 5sec interval was keeping the drive very active

[Herton R. Krzesinski (herton)]

I took a look at logs, the DSDT from AcpiTables and the toshiba_{bluetooth,acpi} code, and seems your machine for some reason gets repeated bluetooth status events after rfkill blocks bluetooth through toshiba_acpi, at least it looks like what's happening.

I'm curious to see what status toshiba_bluetooth is getting, please test the kernel I uploaded at http://people.canonical.com/~herton/lp750428/

You can install it with sudo dpkg -i linux-image-2.6.38-8-generic_2.6.38-8.41~lp750428r1_i386.deb

Reboot, do the same test, and attach the resulting dmesg here. Although your original test is with 2.6.35, the newer kernel doesn't have any relevant changes in toshiba_acpi or toshiba_bluetooth, but I'm curious to see also if behaviour is different with it.

[Daniel Stöckner (da567l)]

Same problem here. Herton, unfortunately, I can't test your kernel, because I have a x86_64 system. Is it possible for you to generate a x86_64 kernel? I would be glad to test it on my system! Thank you in advance!

[porg (porg)]

So, are you asking me to perform this test on my Toshiba? Or someone else?
And if so, will there be a way to revert to the then previous state, after my test, meaning restoring the kernel, which I have right now?

[Daniel Stöckner (da567l)]

Herton generated a kernel image, which can be installed additionally to any existing kernel. After install and reboot, grub lets you choose, which kernel you want to boot, before the system boots into linux. When you're done, you can safely remove Hertons kernel and reboot again. The entry in grub will be removed, while your original kernel is left untouched.

[porg (porg)]

Haven't used my Toshiba laptop for a while.

Before I tried using your patch, I tried to reproduce the bug, but failed to do so (luckily!).
Neither on kernel 2.6.35-28 (for which I originally submitted my bug report ) nor on 2.6.35-30 did the bug happen.
Btw, 2.6.35-30 is the default boot choice meanwhile. Maybe I had some updates since then? I cannot recall, as I rarely use my Toshiba laptop.
When Bluetooth was turned off in the menu, the syslog showed some Bloetooth shutdown messages, but then it remained quiet.

Therefore I conclude there is no real sense in conducting the test with your patch for 2.6.38-8.41.
If I am wrong, tell me so, otherwise SOLVED, thanks, and have a nice time ;-)

[Herton R. Krzesinski (herton)]

Ok, please set status back to Confirmed if you manage to reproduce again.

[porg (porg)]

Message received. Should I ever encounter this problem again, I will continue reporting here. Bye and thanks!

[Jochen Fahrner (jofa)]

I have the same problem on my Satellite Pro U200. After disabling bluetooth with "rfkill block bluetooth", I get these "toshiba_bluetooth: Re-enabling Toshiba Bluetooth" messages every 5 seconds.

Are there alternative ways to disable bluetooth?

[Jochen Fahrner (jofa)]

I made a kernel with the debug patch applied. See attached dmesg.txt

[Jochen Fahrner (jofa)]

One thing to mention: these 5 second polls only happen when bluetooth is disabled via bluetooth applet. If it is disabled via rfkill switch (which also disables wifi, and is not what I want), this polling does not happen.

What does this code mean?

       res1 = acpi_evaluate_integer(handle, "BTST", NULL, &result);
        if (ACPI_FAILURE(res1))
                return res1;
        printk(KERN_INFO "toshiba_bluetooth: BTST result = 0x%08x\n", result);
        if (!(result & 0x01))
                return 0;

Does it test if the rfkill switch is on/off?
This may explain why the polling is not executed when disabled by switch. Then there is a second test missing, which tests if bluetooth is disabled by applet.

[Jochen Fahrner (jofa)]

I did some more testing and found that a notify event 0x90 is triggered every 5 seconds when rfkill switch is on and bluetooth usb module is detached. The notify event 0x90 is described in this article: http://lwn.net/Articles/367630/

Which instance triggers this event repeatedly (every 5 seconds), when bluetooth should be off? I think this should not happen.

[halo9en (knightfall-0)]

This bug still affects me, using the latest iso + kernel 3.17 on a new toshiba laptop.

When I switch bluetooth off, the module keeps trying to reenable every few seconds and the logs are filled with debug messages identical to this:

toshiba_bluetooth: Re-enabling Toshiba Bluetooth
USB disconnect, device number 17
usb 2-8: new full-speed USB device number 18 using xhci_hcd
usb 2-8: New USB device found, idVendor=8087, idProduct=07dc
usb 2-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Bluetooth: hci0: read Intel version: 370710010002030d00
usb 2-8: USB disconnect, device number 18
(and so on...)

[halo9en (knightfall-0)]

No reply, no updates... is there any chance of seeing a fix for this?

[H. Jonker (hljonker)]

Same problem here. The repeating message in DMESG output is:
[ 1683.459073] toshiba_bluetooth: Re-enabling Toshiba Bluetooth
[ 1683.541228] usb 1-1.2: USB disconnect, device number 88
[ 1684.053096] usb 1-1.2: new full-speed USB device number 89 using ehci-pci
[ 1684.246487] usb 1-1.2: New USB device found, idVendor=8087, idProduct=07da
[ 1684.246499] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Interestingly enough, all this re-enabling is increasing the interface number:

$ rfkill list
...
340: hci0: Bluetooth
 Soft blocked: yes
 Hard blocked: no
...

(wait a bit)
$ rfkill list
...
357: hci0: Bluetooth
 Soft blocked: yes
 Hard blocked: no
...

[juukemb (juukembo)]

Reported here: https://bugzilla.kernel.org/show_bug.cgi?id=93911

[juukemb (juukembo)]

A patch has been provided, works fine for me. Please help testing it https://bugzilla.kernel.org/show_bug.cgi?id=93911

[Luca Donetti (donetti-9)]

I suffer the same bug and I can confirm that the patch provided in the kernel bug tracker works for me.

[Tamas K Lengyel (tamas-s)]

I had the same problem on Debian Jessie (Linux l1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) x86_64 GNU/Linux), the provided patch works for me!