|Summary:||Built-in Bluetooth not enabled correctly on Thinkpad T41.|
|Product:||Drivers||Reporter:||Paul Martin (pm)|
|Component:||Platform||Assignee:||Henrique de Moraes Holschuh (hmh)|
|Severity:||normal||CC:||hmh, maciej.rutecki, rjw|
|Kernel Version:||2.6.32 onwards||Tree:||Mainline|
|Bug Depends on:|
ACPI dump of Thinkpad T41
lsusb -v -v output for the device concerned.
Description Paul Martin 2010-02-07 00:31:43 UTC
Created attachment 24933 [details] ACPI dump of Thinkpad T41 Regression from 2.6.31. On boot, 2.6.31 enables the built-in bluetooth adaptor and correctly configures it for operation. 2.6.32 doesn't enable it, but it can be enabled using # echo enable >/proc/acpi/ibm/bluetooth # hciconfig hci0 up 2.6.33-rc6 doesn't enable it either (but "echo enable..." works). However the "hciconfig...up" fails with an error, and it's not possible to get the device to work.
Comment 1 Paul Martin 2010-02-07 00:44:54 UTC
Created attachment 24934 [details] lsusb -v -v output for the device concerned.
Comment 2 Paul Martin 2010-02-07 12:18:50 UTC
This is with 2.6.33-rc7: root@thinkpad:~# hciconfig hci0: Type: USB BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:0 acl:0 sco:0 commands:0 errors:0 root@thinkpad:~# hciconfig hci0 down root@thinkpad:~# hciconfig hci0 up Can't init device hci0: Unknown error 132 (132)
Comment 3 Paul Martin 2010-02-08 23:36:01 UTC
Hold on a bit. I'm not so sure about this. I had need to reset the BIOS to factory settings, and the boot into 2.6.33-rc7 immediately afterwards worked. I'll do some more tests and report back.
Comment 4 Henrique de Moraes Holschuh 2010-02-09 02:03:49 UTC
If it is indeed a bug, it is likely in thinkpad-acpi, so I am assigning this report to myself. Please check the patch on bug #14545. If the bluetooth stack and its fake software-only rfkill switch loads before thinkpad-acpi, you will get whatever is the default state for the rfkill core. If thinkpad-acpi loads first, you are supposed to get whatever state was active when you last rebooted/shut down. Thinkpad-acpi will tell you whatever it is doing to the radios if you give it the debug=4 parameter.
Comment 5 Paul Martin 2010-02-09 03:01:50 UTC
You've got it! It *is* the software-only rfkill function that's causing the error. Using "/usr/sbin/rfkill block|unblock bluetooth" works, where "echo enable > /proc/acpi/ibm/bluetooth" doesn't. Using /usr/sbin/rfkill toggles both switches.
Comment 6 Henrique de Moraes Holschuh 2010-02-09 14:49:48 UTC
Ok. It is good to know, and it is probably something worth documenting. Still, I'd really like to field-test the patch on bug #14545 in a T4x... Perhaps you could help me with that? You'd need to blacklist the bluetooth stack modules (so that they don't load on reboot/startup), and test the thinkpad-acpi rfkill functionality for bluetooth across suspend, reboot and shutdown. I'd appreciate if you could test that it is always restoring the radio to the last state when you suspend/resume, reboot, and shutdown+power-up... i.e. if it was enabled when you suspend/reboot/shutdown, it has to be enabled when you resume/reboot/power up, and if it was disabled, it has to remain disabled. If you do that testing, please report what you find to bug #14545. Thank you. I will close this bug as resolved documented, and send the documentation patch on the next merge window (also for -stable). If you find out there is indeed something else going wrong, feel free to reopen the bug.
Comment 7 Paul Martin 2010-02-09 16:29:37 UTC
It certainly remembers its state across reboot and shutdown. I'm unable to test suspend, as that's broken (again) in 2.6.33-rc7. eg. thinkpad_acpi: tpacpi_rfk_hook_set_block: request to change radio state to blocked thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is blocked