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.
Created attachment 24934 [details] lsusb -v -v output for the device concerned.
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)
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.
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.
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.
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.
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