[gelöst] Udev-Regel für Bluetooth-Device

Lieber Besucher, herzlich willkommen bei: GentooForum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Ignatz

Schüler

Beiträge: 134

31.12.2008, 14:28

Udev-Regel für Bluetooth-Device

Hallo,

ich habe in diesem Thread von der Umstellung meines Systems auf baselayout-2 und openrc >= 0.4.0 berichtet. Dabei ist ein Problem beim Bootvorgang aufgetreten und zwar kommt es zu einer Verzögerung beim Start des udev-Dienstes.
Die Ausgabe habe ich jetzt mal von Hand protokolliert:

Quellcode

starting udev
Populating /dev with existing devices through uevents...
Waiting for uevents to be processed...
devfs     |* devfs: waiting for udev
devfs     |* devfs: waiting for udev
devfs     |* devfs: waiting for udev
devfs     |* devfs: waiting for udev
devfs     |* devfs: waiting for udev
devadm settle timeout of 60 seconds reached, the event queue contains:
'sys/class/bluetooth/hci0' [876]

Nach dieser Ausgabe, die wie gesagt genau eine Minute wartet, geht der Bootvorgang ganz normal weiter.

An der Ausgabe ist zu erkennen, dass das Problem mit dem Bluetooth-Device zusammenhängt. Dazu ist zu sagen, das ich dieses schon immer unter Gentoo nutze. Bluetooth ist in meinem Laptop integriert und ich arbeite mit einer Bluetooth-Maus. Das hat bisher prima funktioniert, auch nach dieser Meldung beim Start. Nur der Bootvorgang wird dadurch verzögert, was lästig ist!

Meine Frage: Was kann ich tun, um das abzustellen?
Benötige ich eine spezielle Udev-Regel? Wenn ja, kann mir dabei jemand helfen? So richtig steige ich bei den Udev-Regeln nämlich nicht durch.
Folgende Regel existiert bereits unter /etc/udev/rules.d/70-bluetooth.rules:

	Quellcode
1 2 3	# Bluetooth devices: # KERNEL=="hci[0-9]*", RUN+="/lib/udev/bluetooth.sh"

Das Script "bluetooth.sh", welches hier aufgerufen wird, sieht so aus:

Quellcode

#!/bin/sh
#
# bluetooth.sh: udev external RUN script
#
# Copyright 2005-2006 Henrik Brix Andersen <brix@gentoo.org>
# Distributed under the terms of the GNU General Public License v2

script=/etc/init.d/bluetooth

# Find out where sysfs is mounted. Exit if not available
sysfs=`grep -F sysfs /proc/mounts | awk '{print $2}'`
if [ "$sysfs" = "" ]; then
    echo "sysfs is required"
    exit 1
fi

if [ ! -d $sysfs/class/bluetooth/hci[0-9]* ]; then
    if $script --quiet status; then
        $script stop
    fi
else
    if ! $script --quiet status; then
        $script start
    fi
fi

Hier noch eine Ausgabe:

Quellcode

ignatz@gentoo ~ $ ls -l /sys/class/bluetooth/hci0
insgesamt 0
-r--r--r-- 1 root root 4096 31. Dez 14:03 address
lrwxrwxrwx 1 root root    0 31. Dez 14:20 bluetooth:hci0:42 -> hci0:42
-r--r--r-- 1 root root 4096 31. Dez 14:20 class
lrwxrwxrwx 1 root root    0 31. Dez 14:03 device -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0
-r--r--r-- 1 root root 4096 31. Dez 14:20 features
drwxr-xr-x 3 root root    0 31. Dez 14:03 hci0:42
-r--r--r-- 1 root root 4096 31. Dez 14:20 hci_revision
-r--r--r-- 1 root root 4096 31. Dez 14:20 hci_version
-rw-r--r-- 1 root root 4096 31. Dez 14:20 idle_timeout
-r--r--r-- 1 root root 4096 31. Dez 14:20 inquiry_cache
-r--r--r-- 1 root root 4096 31. Dez 14:20 manufacturer
-r--r--r-- 1 root root 4096 31. Dez 14:20 name
drwxr-xr-x 2 root root    0 31. Dez 14:20 power
-rw-r--r-- 1 root root 4096 31. Dez 14:20 sniff_max_interval
-rw-r--r-- 1 root root 4096 31. Dez 14:20 sniff_min_interval
lrwxrwxrwx 1 root root    0 31. Dez 14:03 subsystem -> ../../bluetooth
-r--r--r-- 1 root root 4096 31. Dez 14:03 type
-rw-r--r-- 1 root root 4096 31. Dez 14:20 uevent

Und ein Ausschnitt aus dmesg, der wahrscheinlich auch damit zu tun hat:

Quellcode

__set_isoc_interface: hci0 setting interface failed (71)
usb 4-1: USB disconnect, address 2
btusb_intr_complete: hci0 urb f63201c0 failed to resubmit (19)
btusb_bulk_complete: hci0 urb f6dce6c0 failed to resubmit (19)
btusb_bulk_complete: hci0 urb f6dce640 failed to resubmit (19)
__set_isoc_interface: hci0 setting interface failed (19)
btusb_send_frame: hci0 urb f6dce640 submission failed
usb 4-1: new full speed USB device using uhci_hcd and address 3
usb 4-1: configuration #1 chosen from 1 choice
hci_cmd_task: hci0 command tx timeout
usb 4-1: New USB device found, idVendor=0b05, idProduct=1712
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=3
usb 4-1: SerialNumber: 0194E8-5B-0002
usb 4-1: USB disconnect, address 3
btusb_intr_complete: hci0 urb f6dce940 failed to resubmit (19)
btusb_send_frame: hci0 urb f6dce940 submission failed
usb 4-1: new full speed USB device using uhci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
usb 4-1: New USB device found, idVendor=0b05, idProduct=1712
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=3
usb 4-1: SerialNumber: 0194E8-5B-0002
input: Logitech Bluetooth Mouse as /class/input/input9

Vielleich kann ja jemand erkennen was nötig ist, um das Problem zu beheben. Wie gesagt, die Maus funktioniert, auch eine Verbindung mit einem Handy hatte ich schon aufgebaut. Er stört sich nur beim Booten an irgendwas und das nur ab openrc >= 0.4.0. Bei openrc-0.3.1 tritt dieses Problem nicht auf!

Gruß,
Ignatz

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Ignatz« (02.01.2009, 16:48)

Zum Seitenanfang

bell

Erleuchteter

Beiträge: 3 128

01.01.2009, 14:52

Wie es aussieht funktioniert irgendwas mit bluetooth hotplug noch nicht richtig. Hilft es dir, wenn Du folgendes in die /etc/rc.conf einträgst?

	Quellcode
1	rc_hotplug="!bluetooth *"

Gibt es Probleme mit /etc/init.d/bluetooth ?

Auch wenn Open-Source kostenlos ist, ist sie nicht umsonst. Dein Preis ist Dein Engagement und Mitarbeit an OS-Projekten.
Wenn Du keinen Preis bezahlen willst, bist Du die Ware. Und das ist nicht Open Source, geschweigedenn frei.

Zum Seitenanfang

Ignatz

Schüler

Beiträge: 134

01.01.2009, 17:59

Hallo bell,

der Eintrag in die /etc/rc.conf bewirkt nichts. Ich glaube, der Bluetooth-Dienst wird über coldplugging gestartet. Jedenfalls bewirkt ein Eintrag in /etc/conf.d/udev

	Quellcode
1	rc_coldplug="NO"

, dass das Problem beim Booten nicht mehr auftritt. Aber dafür habe ich anschließend kein Bluetooth und z. B. auch kein Netzwerk mehr.

Zu /etc/init.d/bluetooth

Quellcode

ignatz@gentoo ~ $ sudo /etc/init.d/bluetooth restart
bluetooth               |* Shutting down Bluetooth...
bluetooth               |*     Stopping hidd...                                                       [ ok ]
bluetooth               |*     Stopping sdpd...                                                       [ ok ]
bluetooth               |*     Stopping hcid...                                                       [ ok ]
bluetooth               |* Starting Bluetooth...
bluetooth               |*     Starting hcid...                                                       [ ok ]
bluetooth               |*     Starting sdpd...                                                       [ ok ]
bluetooth               |*     Starting hidd...                                                       [ ok ]

das läuft problemlos durch.

Zum Seitenanfang

dyle

Erleuchteter

Beiträge: 4 869

02.01.2009, 12:43

Hm ... gib dem OpenRC-Typen doch mal einen Wink und stell ein Ticket rein: http://roy.marples.name/projects/openrc

http://www.dyle.org
IM-Account (Jabber!) sind auf meiner HP ...
There is no place like /home

http://www.gentooforum.de
http://www.gentoofreunde.org

<div>how to annoy a web developer?</span>

Zum Seitenanfang

maggu2810

OSI Layer 8

Beiträge: 5 552

02.01.2009, 12:59

coldplug kannst du schon ausschalten, aber dann musst dich halt einmalig um den korregten Start etwaiger Dienste und Module selber kümmern.

Könntest du nach dem "${sript} start" mal noch ein "&" anhängen und schauen, obs dann schneller geht?

"Erst nachdem wir alles verloren haben, haben wir die Freiheit, alles zu tun."
"It's only after we've lost everything, that we're free to do anything!"

Jabber: Die ID kann via PN erfragt werden.

Zum Seitenanfang

Ignatz

Schüler

Beiträge: 134

02.01.2009, 16:47

Der Hinweis mit dem sysinit-Runlevel hat mir weitergeholfen.
Nach ein bisschen probieren sieht der jetzt bei mir so aus:

	Quellcode
1 2 3 4 5 6 7	ignatz@gentoo ~ $ sudo rc-update show sysinit mtab \| sysinit udev \| sysinit devfs \| sysinit dmesg \| sysinit procfs \| sysinit bluetooth \| sysinit

Damit ist die hässliche Verzögerung beim Booten verschwunden und der Bootvorgang läuft ohne Fehler durch. procfs und mtab habe ich aus dem Boot-Runlevel entfernt und bluetooth aus dem Default-Runlevel. Ob das die feine Englische ist, weiß ich nicht. Aber es funktioniert so!

Gruß,
Ignatz

Zum Seitenanfang

GentooForum.de