[Cc: +regressions@xxxxxxxxxxxxxxx]
Dear JLM,
Am 13.04.23 um 00:06 schrieb help.7ocym@xxxxxxxxxxx:
sorry to address both list, but this issue seems related, without
knowing where lies the issue > my hardware : https://wiki.gentoo.org/wiki/Lenovo_Yoga_900
I use the pre-built gentoo linux kernel,
6.2.8-gentoo-dist #1 SMP PREEMPT_DYNAMIC Wed Mar 22 17:15:39 -00 2023 x86_64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz GenuineIntel GNU/Linux
since a few update (sadly I didn't noted the latest kernel version
that didn't had the issue), after a boot, the bluetooth isn't
working, nothing bad in dmesg, I just have to unload btusb module and
modprobe it again to have bluetooth working again...
after a suspend to ram, I have to power off-power on the bluetooth to
have it work again (bluetoothctl power off; bluetoothctl power on)
bluetooth mouse can also be extremely laggy sometimes,but without
error message in dmesg, most of the time `bluetoothctl power` off-on
cycling do solve the issue....
I also included the usb mailing list because it might be related to
some behavior I noticed :
I have usb3.0 micro sd card reader (SanDisk MobileMate UHS-I microSD
Reader/Writer USB 3.0 Reader, Kingston MobileLite Plus (MLPM) microSD
Card Reader USB 3.1 microSDHC/SDXC UHS-II, for example) and some
extra fast micro sd cards (like sandisk extrem 512G), when
transferring data the read rate can be as high as 110Mo/s and write
70Mo/s sustained, nothing impressive but when such rate is achieved
for a long time (big file transfer) either reading only access,
writing only access or read write, the usb bus become unusable, I
can't even use a usb mouse connected to it by wire... even if cpu
usage is really low (less than 10%) I don't have the issue if I
connect a M2 usb3 flash drive, with comparable transfert speed... so
not related to some bus over usage...
so I suspect that there is an issue with the usb driver, and that
maybe the bluetooth issue can be related to the usb issue, since the
bluetooth controller is on the usb bus on the laptop >
the transfer issue of usb is much more older than the bluetooth
issue, it's approximative, but : > - the btusb boot issue is about 3 month old,
- the suspend/resume issue of bluetooth is more than a year old
- the usb transfer issue as more than a year...
I'll gladly provide any useful information, can also do patch tries...
As you use Gentoo and are able to build your own Linux kernel, the
fastest way to get these issues addressed is to bisect them. To shorten
the test cycles, I recommend to try, if you can reproduce the issues in
QEMU and passing through the problematic devices to the VM [1][2].
I also recommend to start a separate thread for each issue and, as these
seem to be regressions, also keep the regression folks in the loop [3].
Kind regards,
Paul
[1]:
https://lore.kernel.org/all/5891f0d5-8d51-9da5-7663-718f301490b1@xxxxxxxxxxxxx/
(The commands were working for after all, and the device didn’t
show up due to a (second) Linux kernel regression.)
[2]: https://station.eciton.net/qemu-usb-host-device-pass-through.html
[3]:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-regressions.html
