You are not logged in.
Pages: 1
Hello. When I turn on my laptop without charging, everything is fine. If I turn it on while charging, the bluetooth module just disappears. I have to completely turn off the laptop(not reboot)(coldboot) and disconnect the power cable. What can I do about this?
OS : Arch Linux x86_64
Kernel : Linux 6.12.1-arch1-1
WM : Hyprland (Wayland)
Offline
Post two sets of boot logs. One with the charging cable removed, one with the charging cable plugged in. Please post full boot logs: https://wiki.archlinux.org/title/List_o … n_services
Run
journalctl -b
to get logs from the current boot. You can specify
journalctl -b -1
to get logs from the previous boot, or specify other integers for other previous boots.
Last edited by pvtvega (2024-12-04 17:32:58)
Offline
With cable http://0x0.st/X7pU.txt
Without cable http://0x0.st/X7pG.txt
Offline
In your first log, with cable, right before NetworkManager starts, there is an entry:
дек 05 00:43:12 cyberlair systemd[1]: shadow.service: Deactivated successfully.
What is shadow.service? I don't see this in the second boot log (without cable). This shadow.service also terminates immediately after starting login management, and in the "correct" boot logs the Bluetooth modules begin to load immediately after the same line.
EDIT: I did some further reading and shadow.service is related to credential management for users/groups. Still curious why it's present in one boot log but not the other.
Last edited by pvtvega (2024-12-04 19:17:55)
Offline
Another thing: can you provide the outputs of:
systemctl status -u bluetooth.service
and
lsmod | grep -E 'bt|bluetooth'
When you boot with the cable plugged in, can you manually load the Bluetooth kernel module?
Offline
Another thing: can you provide the outputs of:
systemctl status -u bluetooth.service
and
lsmod | grep -E 'bt|bluetooth'
When you boot with the cable plugged in, can you manually load the Bluetooth kernel module?
○ bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: disabled)
Active: inactive (dead)
Docs: man:bluetoothd(8)
дек 05 02:29:13 cyberlair systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
дек 05 02:29:13 cyberlair systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
The output of the second command is empty
Offline
Can you manually load the module
modprobe btusb
EDIT: the module you want might just be called Bluetooth, on my system I have a Bluetooth card installed on a USB header which is why I recommended btusb. Your system also uses btusb, but I'm not 100% positive if you also need a Bluetooth module.
And then try
systemctl start bluetooth.service
Last edited by pvtvega (2024-12-04 19:45:04)
Offline
Can you manually load the module
modprobe btusb
EDIT: the module you want might just be called Bluetooth, on my system I have a Bluetooth card installed on a USB header which is why I recommended btusb. Your system also uses btusb, but I'm not 100% positive if you also need a Bluetooth module.
And then try
systemctl start bluetooth.service
Sorry for the long absence, on charging, if I use sudo modprobe btusb and then press the bluetooth enable buttons on my laptop (Fn+F5) a few times, then everything works. Before that, systemctl gives that bluetooth service was not started
Offline
From the good boot:
дек 05 00:47:49 cyberlair systemd[1]: Starting Load/Save RF Kill Switch Status...
дек 05 00:47:49 cyberlair kernel: usbcore: registered new interface driver btusb
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Device revision is 2
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Secure boot is enabled
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: OTP lock is enabled
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: API lock is enabled
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Debug lock is disabled
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 38
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: DSM reset method type: 0x00
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Found device firmware: intel/ibt-0040-4150.sfi
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Boot Address: 0x100800
дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Firmware Version: 91-33.24
then press the bluetooth enable buttons
W/o pressing anything, boot into the compromised condition and check "rfkill".
You should™ not have to load the module, if the device shows up, it should™ be loaded automatically.
Online
From the good boot:
дек 05 00:47:49 cyberlair systemd[1]: Starting Load/Save RF Kill Switch Status... дек 05 00:47:49 cyberlair kernel: usbcore: registered new interface driver btusb дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Device revision is 2 дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Secure boot is enabled дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: OTP lock is enabled дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: API lock is enabled дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Debug lock is disabled дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014 дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 38 дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: DSM reset method type: 0x00 дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Found device firmware: intel/ibt-0040-4150.sfi дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Boot Address: 0x100800 дек 05 00:47:49 cyberlair kernel: Bluetooth: hci0: Firmware Version: 91-33.24
then press the bluetooth enable buttons
W/o pressing anything, boot into the compromised condition and check "rfkill".
You should™ not have to load the module, if the device shows up, it should™ be loaded automatically.
When calling rfkill on a charge:
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
Last edited by kushiko (2024-12-08 14:47:24)
Offline
Please don't bloat the thread with pointless full quotes of previous posts.
What's the output of
lsusb -tv
when the bt device is available?
Online
lsusb -tv with the module running (without charging):
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 20000M/x2
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 003: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 2571:4101
|__ Port 003: Dev 002, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 2571:4101
|__ Port 005: Dev 003, If 0, Class=Video, Driver=uvcvideo, 480M
ID 090c:337b Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Silicon Motion Camera
|__ Port 005: Dev 003, If 1, Class=Video, Driver=uvcvideo, 480M
ID 090c:337b Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Silicon Motion Camera
|__ Port 007: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 12M
ID 258a:010c
|__ Port 007: Dev 004, If 1, Class=Human Interface Device, Driver=usbhid, 12M
ID 258a:010c
|__ Port 010: Dev 005, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0026 Intel Corp. AX201 Bluetooth
|__ Port 010: Dev 005, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0026 Intel Corp. AX201 Bluetooth
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
Last edited by kushiko (2024-12-10 13:15:43)
Offline
ID 258a:010c seems "BY Tech Gaming Keyboard"?
And there's a webcam on the hub - internal? Can you deactivate it in the BIOS?
The idea would be to clear the bus (remove the keyboard or move it to another hub) and see whether that has any impact on the situation.
Online
Here's lsusb -tv with the camera disabled and without USB devices:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 20000M/x2
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
Same thing with working bluetooth:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 20000M/x2
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 010: Dev 002, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0026 Intel Corp. AX201 Bluetooth
|__ Port 010: Dev 002, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0026 Intel Corp. AX201 Bluetooth
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
Last edited by kushiko (2024-12-11 04:07:15)
Offline
Iow those devices don't nuke the BT device.
Since I haven's asked: is there a parallel windows installation on that system?
(There're only 2 nvme partitions, so probably not?)
This sounds insane, but try to add i915 to the initramfs MODULES array in mkinitcpio.conf (and regenerate the initramfs)
Online
I have only Arch installed
Offline
try to add i915 to the initramfs MODULES array in mkinitcpio.conf (and regenerate the initramfs)
It didn't work
Offline
Was an insane idea just because i915 loads late and cuts straight into the USB setup in the disfunctional case.
Can you post an updated journal (w/ the charger active)?
It's still probably that the system runs/boots at higher speed.
You can plug the AC fine after booting w/o and that ha no whatsoever impact on you BT or any other USB device?
One more thing: is the device charged via an USB port?
Online
If I put the device on charge a little later after startup, everything works fine. The device is charged via normal DC. http://0x0.st/Xh3w.txt
Last edited by kushiko (2024-12-11 08:31:31)
Offline
'key.
Actually the usb devices show up that early, you probably had the kms hook active, i915 still runs into that process, so I'm not letting it off the hook.
Remove the module from the array and also the "kms" from HOOKS.
If that doesn't help, try to add "module_blacklist=i915 systemd.unit=multi-user.target" and in doubt "nomodeset" to the https://wiki.archlinux.org/title/Kernel_parameters
You won't get a GUI (resp. only can run it on the simpledrm device when booting w/o nomodeset) but can check the presence of the BT device on the console.
If it's still not there despite i915 not loading at all ("lsmod | grep 915"), i915 is off the hook and we'll have to come up w/ sth. even more insane…
Online
Here's my mkinitcpio.conf. I will rebuild and reboot now. MODULES=() BINARIES=() FILES=() HOOKS=(base udev autodetect microcode modconf keyboard keymap consolefont block filesystems fsck).
Unfortunately that didn't help.
Last edited by kushiko (2024-12-11 09:16:07)
Offline
The second method didn't help either. I specified in the kernel parameters "module_blacklist=i915 systemd.unit=multi-user.target nomodeset" http://0x0.st/XhY1.txt
Last edited by kushiko (2024-12-11 09:27:31)
Offline
The journal of that boot woud be more interesting than lsusb.
I assume the CPU or RAM or both clock higher when on AC and that somehow™ triggers a race condition - what if you boot on AC but w/ "maxcpus=1"?
maxcpus= [SMP] Maximum number of processors that an SMP kernel
will bring up during bootup. maxcpus=n : n >= 0 limits
the kernel to bring up 'n' processors. Surely after
bootup you can bring up the other plugged cpu by executing
"echo 1 > /sys/devices/system/cpu/cpuX/online". So maxcpus
only takes effect during system bootup.
While n=0 is a special case, it is equivalent to "nosmp",
which also disables the IO APIC.
It's however rather weird and also probably easier to just not boot w/ the charger plugged…
If you boot w/ the charger, no kernel commandline shenanigans, and then run
echo 1 | sudo tee /sys/bus/pci/rescan
, does the BT device appear?
Online
Unfortunately the device didn't show up
Offline
For maxcpu's, the pci rescan or either?
Add "boot_delay=50" to the https://wiki.archlinux.org/title/Kernel_parameters which should considerably slow down the entire boot process.
Does that get you the BT device w/the charger attached?
(Not as a solution, obviously, but to figure whether this is some sort of race condition that gets exposed by a faster boot when the system has external power supply)
Online
Pages: 1