Hallo liebe Community,
nachdem hier im USB-Forum ja recht lange nichts nennenswertes mehr los war, hab ich mal wieder ein Problemchen.
Wie der Titel schon verrät habe ich bei einigen USB-Sticks (zwei um genau zu sein, drei andere funktionieren einwandfrei) die Eigenheit, dass der dbus-daemon sobald der Stick dransteckt anfängt, folgendes zu loggen:
Am Anfang ist noch ein bisschen was vom Kernel, der wie erwartet sofort nach dem Einstecken des Sticks das Device anlegt, heißt ab da kann ich sofort /dev/sdf1 (o.ä.) von Hand mounten. Im KDE/Gnome (KDE aufm Rechner, Gnome aufm Laptop, bei beiden das gleiche Verhalten) erscheint der Stick aber vorerst nicht im Filemanager/USB-Tray. Dann legt der dbus-daemon los und spammt das, was zwischen "-1-" steht, extrem oft (schätzungsweise 500-1000 mal, genau gezählt hab ich das nicht). Das braucht so ca. dreißig Sekunden, dann kommt das bei "-2-" im Log und wie man sieht kann ich danach das Ding über das USB-Tray in KDE wie gewohnt einbinden (erkennbar an "USING MOUNT OPTIONS..."). In Gnome erscheint der Stick nach der Wartezeit nicht im USB-Tray/Nautlius, vielleicht gibt der irgendwann, wenn zu viele Meldungen von dbus kommen, die Verbindung auf (nur eine Vermutung).
Gelegentlich kommt mitten im Spam eine 5-Sekunden-Pause mit folgender Message:
Kurz später geht der Spaß aber wieder los und ich habe wieder nen ganzen Haufen von obigem Log.
Problem ist also, dass ich bei den Sticks erst 30 Sekunden warten muss, bis ich sie (zumindest unter KDE) verwenden kann. Während der dbus-daemon spammt, blinken die beiden Sticks auch dauerhaft, heißt irgendwas machen die mit dem Stick - evtl. wird irgendwas gepollt o.ä., ich habe allerdings keine Ahnung was.
Beim Googlen sind mir ausschließlich Diskussionen aufgefallen, die sich über 100%ige CPU-Auslastung von dbus beschweren. Bei mir schaut das während der spammerei nur so aus:
Ich denke dass 7% nicht wirklich ins Gewicht fallen, dafür dass er so viele Zeilen auf einmal ins syslog schreibt. Interessant ist vielleicht, dass udisks nebenbei auch einiges arbeitet, da ich allerdings nicht weiß, wie der mit der ganzen Geschichte zusammenhängt, will ich hier keine Vermutungen anstellen - hab dafür aber die Versionsnummer angegeben.
Folgende Infos zu Hard- und Software:
USB-Sticks:
PC und Laptop sind im Prinzip identisch eingerichtet:
Zuguterletzt der altbekannte Satz: Unter Windows funktionieren die Sticks einwandfrei und sofort.
Hat irgendwer von euch einen Ansatz, woran das liegen könnte? Oder zumindest eine Idee, wie man rausbekommt, warum der dbus-daemon "denkt" das Device würde ein "CHANGING"-Signal notwendig machen?
Ich hoffe blos nicht, das ich beim Googlen die Lösung einfach vor lauter "CHANGING"...-Spam übersehen habe
Wenn Interesse besteht, könnte ich vielleicht mal ein kleines Video machen, dann ist das vielleicht einfacher zu verstehen als mein Roman hier.
Gruß und schonmal Danke!
Fabian
nachdem hier im USB-Forum ja recht lange nichts nennenswertes mehr los war, hab ich mal wieder ein Problemchen.
Wie der Titel schon verrät habe ich bei einigen USB-Sticks (zwei um genau zu sein, drei andere funktionieren einwandfrei) die Eigenheit, dass der dbus-daemon sobald der Stick dransteckt anfängt, folgendes zu loggen:
Code:
Apr 10 18:11:30 artex kernel: [16250.841969] scsi 15:0:0:0: Direct-Access Hama FlashPen 6.16 PQ: 0 ANSI: 0 CCS
Apr 10 18:11:30 artex kernel: [16250.842550] sd 15:0:0:0: Attached scsi generic sg7 type 0
Apr 10 18:11:30 artex kernel: [16250.844298] sd 15:0:0:0: [sdf] Attached SCSI removable disk
Apr 10 18:11:30 artex dbus-daemon[1245]: **** ADDING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** UPDATING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** ADDED /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** EMITTING ADDED for /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
-1-
Apr 10 18:11:30 artex dbus-daemon[1245]: **** CHANGING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** UPDATING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** CHANGED /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
-1-
Apr 10 18:11:30 artex dbus-daemon[1245]: **** CHANGING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** UPDATING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:11:30 artex dbus-daemon[1245]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
[...]
Apr 10 18:12:26 artex dbus-daemon[1245]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
Apr 10 18:12:26 artex dbus-daemon[1245]: **** CHANGED /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf
-2-
Apr 10 18:12:26 artex dbus-daemon[1245]: **** ADDING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf/sdf1
Apr 10 18:12:26 artex dbus-daemon[1245]: **** UPDATING /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf/sdf1
Apr 10 18:12:26 artex dbus-daemon[1245]: **** ADDED /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf/sdf1
Apr 10 18:12:26 artex dbus-daemon[1245]: **** EMITTING ADDED for /sys/devices/pci0000:00/0000:00:02.1/usb1/1-1/1-1:1.0/host15/target15:0:0/15:0:0:0/block/sdf/sdf1
-2-
Apr 10 18:12:33 artex dbus-daemon[1245]: **** USING MOUNT OPTIONS 'uhelper=udisks,nodev,nosuid,uid=1000,gid=100,shortname=mixed,dmask=0077,utf8=1,showexec' FOR DEVICE /dev/sdf1
Gelegentlich kommt mitten im Spam eine 5-Sekunden-Pause mit folgender Message:
Code:
Apr 10 18:27:51 artex rsyslogd-2177: imuxsock begins to drop messages from pid 1245 due to rate-limiting
Problem ist also, dass ich bei den Sticks erst 30 Sekunden warten muss, bis ich sie (zumindest unter KDE) verwenden kann. Während der dbus-daemon spammt, blinken die beiden Sticks auch dauerhaft, heißt irgendwas machen die mit dem Stick - evtl. wird irgendwas gepollt o.ä., ich habe allerdings keine Ahnung was.
Beim Googlen sind mir ausschließlich Diskussionen aufgefallen, die sich über 100%ige CPU-Auslastung von dbus beschweren. Bei mir schaut das während der spammerei nur so aus:
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4385 fabian 20 0 2975m 185m 41m S 15 4.7 41:30.25 amarok
1245 messageb 20 0 20804 2640 1156 S 7 0.1 4:01.17 dbus-daemon
2970 root 20 0 126m 4284 3068 S 5 0.1 2:10.42 udisks-daemon
Folgende Infos zu Hard- und Software:
USB-Sticks:
- Hama FlashPen 1GB (57060 v2)
SanDisk Cruzer 16GB
PC und Laptop sind im Prinzip identisch eingerichtet:
- openSUSE 12.1 64bit
Kernel 3.3.1-1-desktop (Laptop 3.3.2)
KDE 4.8.2 (Laptop Gnome 3.2)
dbus-1-1.5.8
udisks-1.0.4
Zuguterletzt der altbekannte Satz: Unter Windows funktionieren die Sticks einwandfrei und sofort.
Hat irgendwer von euch einen Ansatz, woran das liegen könnte? Oder zumindest eine Idee, wie man rausbekommt, warum der dbus-daemon "denkt" das Device würde ein "CHANGING"-Signal notwendig machen?
Ich hoffe blos nicht, das ich beim Googlen die Lösung einfach vor lauter "CHANGING"...-Spam übersehen habe
Gruß und schonmal Danke!
Fabian