I am trying to configure a usb bluetooth device using blueZ. I have configured the kernel according to the howto's. When I run /etc/init.d/bluetooth start the kernel modules get loaded and services indicates [ok] - but it seem like modprobe has a problem. There is a modprobe process hanging which consumes all CPU cycles. Here is its parameters: # ps -w 7017 PID TTY STAT TIME COMMAND 7017 ? R< 56:47 /sbin/modprobe -q -- bt_proto_0 I do not understand where the bt_proto_0 parameter comes from - it is not a module. bt_proto is an array in af_bluetooth.c but I do not know if this relates to each other?? another strange observation: in /proc there are two "bluetooth" folders which are empty?? Reproducible: Always Steps to Reproduce: 1. reboot system 2. plug bluetooth usb dongle 3. execute /etc/init.d/bluetooth start Actual Results: CPU is producing more heat than expected :-) and no bluetooth. some hard facts: laptop trol # lsusb Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 08fd:0002 Digianswer A/S Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 This scenario does not depend on the USB dongle at all - I have tested without any dongle and with a broadcom dongle (acer) laptop trol # hcitool dev Devices: laptop trol # lsmod Module Size Used by rfcomm 35672 - l2cap 23200 - bluetooth 44645 - laptop trol # emerge info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r1, 2.6.1 2-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share /config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kd e/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/q mail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.caliu.info/pub/gentoo/ ftp://chod.cwru.edu/gentoo http ://mirror.gentoo.ru/pub/mirror/gentoo/ http://ftp.caliu.info/pub/gentoo/ http:// gentoo.mirror.icd.hu/ http://mirror.uni-c.dk/gentoo/ http://mirror.uni-c.dk/gent oo/ http://pandemonium.tiscali.de/pub/gentoo/ http://mirror.pudas.net/gentoo htt p://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups dvd eds emboss e ncode foomaticdb fortran gdbm gif gpm gstreamer gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd tiff truetype tru etype-fonts type1-fonts vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc _glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Please try reproducing this with net-wireless/bluez-utils-2.21.
(In reply to comment #1) > Please try reproducing this with net-wireless/bluez-utils-2.21. I have now installed the above mentioned version. I can still make modeprobe hang. However it only happens when no bluetooh device is present when I perform "# /etc/init.d/bluetooth start" If I just make sure to plug the bluetooth device before starting the bluetooth system, then there are no problems. If I start bluetooth with no device plugged - hence having modprobe using 99% cpu, then if I plug the bluetooth device afterwards, the bluetooth functionallity seems to work. The device appears as hci0 in hciconfig and I can find other devices with hcitool scan command. But the modprobe process does not go away. I expect it should be possible to start the bluetooh system without any bluetooth device attached - without the modprobe problem? Please tell me if there is some specific information I can provide. Thanks.
Reopening.
Please attach the output of `modprobe -c` to this bug report and reopen.
Created attachment 71585 [details] output from modprobe -c
See attached file for output from modprobe -c
What does `grep CONFIG_BT_L2CAP /usr/src/linux/.config` say?
(In reply to comment #7) > What does `grep CONFIG_BT_L2CAP /usr/src/linux/.config` say? > > it says.. CONFIG_BT_L2CAP=m
Does modprobe also hang if you manually run `modprobe l2cap` without having a bluetooth adapter plugged in?
(In reply to comment #9) nope - that works fine. I also tried these two commands after a clean boot with no adaptor plugged in: 'modprobe -v bt_proto_0' 'modprobe -q -- bt_proto_0' and they also worked fine.. Then I started to look at the startup script '/etc/init.d/bluetooth' I tried to start the daemons manually in the same order as in the start section. When I came to '/usr/sbin/sdpd' - then modprobe is hanging as I have described previously. - The same happend with rfcomm on a clean boot. I have not tested hidd, dund, pand - if the first one is solved I hope the rest is as well :-)
I can not confirm it here :( Please try running modprobe under `strace` and attach the output here.
Created attachment 73148 [details] strace output from /etc/init.d/bluetooth start
Ok - see the newly attached file - it got quite big, but I made an strace of /etc/init.d/bluetooth start - which covers "real world situation". Pay attention to PID 9197 at the end of the trace (and backwards).
(In reply to comment #13) > Ok - see the newly attached file - it got quite big, but I made an strace > of /etc/init.d/bluetooth start - which covers "real world situation". > Pay attention to PID 9197 at the end of the trace (and backwards). That's hidd - please report this issue upstream to the bluez maintainers.
