Description of problem: since F27 started shipping 4.15.x kernels, the BCM4324B3 bluetooth controller of a Lenovo Yoga 2 Tablet (1051F) doesn't work any more. This is particularly bad for this machine as both keyboard and touchpad are BT devices. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. boot 4.15.x kernel 2. BT doesn't work. Actual results: dmesg: acpi 80860F09:00: Device [PWM1] is in always present list 80860F0A:00: ttyS4 at MMIO 0x9091d000 (irq = 17, base_baud = 2764800) is a 16550A 80860F0A:01: ttyS5 at MMIO 0x9091f000 (irq = 18, base_baud = 2764800) is a 16550A synth uevent: /devices/platform/80860F0A:00/serial0: failed to send uevent synth uevent: /devices/platform/80860F0A:01/serial1: failed to send uevent pwm-lpss 80860F09:00: invalid resource pwm-lpss: probe of 80860F09:00 failed with error -22 mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA mmc2: SDHCI controller on ACPI [80860F14:00] using ADMA input: SYNA0001:00 06CB:1023 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA0001:00/0018:06CB:1023.0003/input/input3 synth uevent: /devices/platform/80860F0A:00/serial0: failed to send uevent synth uevent: /devices/platform/80860F0A:01/serial1: failed to send uevent Expected results: dmesg of pre 4.15 kernel: acpi 80860F09:00: Device [PWM1] is in always present list 80860F0A:00: ttyS4 at MMIO 0x9091d000 (irq = 184, base_baud = 2764800) is a 16550A 80860F0A:01: ttyS5 at MMIO 0x9091f000 (irq = 186, base_baud = 2764800) is a 16550A mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA mmc2: SDHCI controller on ACPI [80860F14:00] using ADMA input: SYNA0001:00 06CB:1023 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA0001:00/0018:06CB:1023.0003/input/input4 Additional info: even though /dev/ttyS4 and 5 are detected early on, they 'break' sometime later in the boot process and are then missing in /dev/. I'd be happy to debug if instructed.
For starters can you attach full dmesg output (do "dmesg > dmesg.log" directly after boot) with a working and a non-working kernel please? With recent kernels the way serial/uart attached bluetooth works has changed and the kernel now does everything automatically so you no longer need to manually run btattach now. But that seems to not be working for you.
Created attachment 1407572 [details] dmesg of working 4.13
Created attachment 1407573 [details] dmesg of broken 4.15
Hi Hans, thanks for the fast reply. I indeed have my 'own' hciattach service which has been working up to 4.14. I now disabled this service and dmesg'd both working 4.13 and non-working 4.15 as requested. thanks, -Christian
Can you do: cat /sys/bus/serial/devices/serial0-0/modalias And let me know the output of that?
Oh and also please do: sudo dnf install acpica-tools acpidump -o acpidump.lenovo-yoga2 And attach the generated acpidump.lenovo-yoga2 file here.
/sys/bus/serial/devices/ is empty on 4.13, but on 4.15 modalias reads: acpi:BCM2E84: acpidump is identical for both kernels and attached above.
Created attachment 1407579 [details] output of acpidump
(In reply to Christian Herzog from comment #7) > /sys/bus/serial/devices/ is empty on 4.13, but on 4.15 modalias reads: > acpi:BCM2E84: Ok, that is the problem, that id is not listed in drivers/bluetooth/hci_bcm.c which causes the new autobind magic to fail. The good news is that with that id added, you will get various power-saving features enabled for bluetooth. Question, can you build your own kernels, or do I need to provide a scratch build to test for you ?
Note I will prepare a patch either way, just wondering if I also need to start a kernel scratchbuild.
I won't compile a kernel on that hardware, but I have other F27 machines I can build on. Awaiting instructions :) thanks, -Christian
Ok, I've written a patch and started a scratch build with the patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=25687085 This is currently building (this takes a couple of hours), once it is finished follow these instructions for testing: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt You should now also have runtime pm active for your bluetooth to test this, run: watch cat /sys/bus/serial/devices/serial0-0/power/runtime_status This will auto-refresh every 2 seconds, stop using all your BT devices and the runtime_status should go to suspended after a bit (and wakeup again when you start using your BT devices again). If the runtime pm statsu says "unsupported" check your dmesg for missing firmware files and download and put the BT patchram update in the requested filename under /lib/firmware.
Note the scratch-build is finished now.
good morning! some progress: thanks for the test kernel, I installed it and indeed, BT shows up. However, I can't pair the BT keyboard/touchpad combo. When I try pairing in the BT settings dialog, most of the time it just jumps back to 'Not Set Up". Occasionally it seems to pair, but then it's 'Disconnected' and I can't get it to connect. I'm wondering if it doesn't load the firmware (which I copied to /lib/firmware/) - I seem to recall that I had similar problems 2 years ago before I started explicitely loading the firmware using brcm_patchram_plus.. any suggestions? thanks, -Christian
Question, what is the output of: dmesg | grep hci0 ? Suggestions: 1) Check in dmesg for errors about missing firmware, it might be the kernel autobind path results in using a different filename then the userspace bits 2) If one does not show anything, try moving the firmware out of /lib/firmware/brcm and reboot then you definitely should get an error in dmesg about it missing. 3) Try putting it back under the name as printed in the error and reboot, the error should be gone now. If you get the error and manage to make it go away, then the firmware is being loaded.
p.s. cat /sys/bus/serial/devices/serial0-0/power/runtime_status Will also let you know if the firmware update was applied, without a firmware update that will return "unsupported"
ha! dmesg told me that I had to rename BCM4324B3_002.004.006.0130.0161.hcd to BCM4324B3.hcd, now it gets loaded and I can pair the keyboard combo! Thanks a lot for your help! Question regarding power saving: this is no good on this machine as it just suspends and then I have no way of waking it up again by pressing a key - how to disable it? I tried echoing 0 > runtime_suspend_time, but that doesn't work. thanks! -Christian
echo on > /sys/bus/serial/devices/serial0-0/power/control seems to do the trick..
Right, note I think I know howto actually fix power-management which would be a better solution I think :) I will prepare another patch + scratchbuild and get back to you.
anytime. for now I have a workaround. thanks again!
Ok, here is a scratch build where bluetooth should just work (including the runtime suspend stuff) without needing any manual configuration, other then the unfortunate need to manually put the firmware in place: https://koji.fedoraproject.org/koji/taskinfo?taskID=25718579 This is currently building (this takes a couple of hours), once it is finished the testing instructions are still at: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Also please test runtime pm, run: watch -n .1 cat /sys/bus/serial/devices/serial0-0/power/runtime_status And after 5 seconds of not using your keyboard it should suspend, and automatically wakeup at your first keypress again.
FYI the scratch build has just completed.
everything works beautifully, suspend, wakeup. Thanks! I'll update my Yoga 2 howto https://daduke.org/linux/yoga.html once the 'official' kernel is out. cheers, -Christian