USB Schnittstelle blockiert jeweils nach siebenter Datenabfrage

  • ok sechster Aufruf- sorry


    sudo fuser -v /dev/bus/usb/001/002 keine Ausgabe

    sudo fuser -v /dev/bus/usb/001/002 keine Ausgabe

  • strace -f te923con # Das ist jetzt der 7. Durchlauf


    nein der verhält sich nicht wie ein Durchlauf, der zählt nicht aber wenn ich ihn nochmal eingebe rennt das Fenster durch.

    i@pizero1:~ $ sudo fuser -v /dev/bus/usb/001/002

    BEN. PID ZUGR. BEFEHL

    /dev/bus/usb/001/002:

    pi 870 F.... te923con


    kill 870


    Fenster eins "killed by sigterm"

    Prompt wieder da

    Einmal editiert, zuletzt von satsatt ()

  • hier die Fortsetzung

  • Das ist schon der Teil, der sich wiederholt. Zum Vergleich mit den erfolgreichen Durchläufen, bräuchte ich die Ausgabe von Anfang an. Tipp:


    sudo strace -f te923con 2>&1 | tee te923con.trace


    schreibt die Ausgabe in eine Datei. Die könntest Du dann hier hochladen oder in irgendein pastebin packen.

  • Hat noch jemand den Durchblick?


    * Offenbar werden Prozesse gestartet von einem daemon. (Nach Kill laeuft wieder ein prozess mit anderer PID)

    * Bei zu vielen offenen USB-Devices haengt der naechste Versuch, das Device zu öffnen. Offenbar sind nur 6 möglich. (8 wäre logischer).


    Also muesstet ihr den daemon finden und beenden.

  • Wie ich schon einmal geschrieben habe, klingt das fast nach einem von systemd nachgestarteten Prozess, der sich z.B. mittels "journalctl -ex" finden lassen sollte.


    Einfach in einem Fenster starten und dann den Prozess killen.

    In dem Fenster mit dem journal sollte sich etwas finden lassen.

    Selber denken,
    wie kann man nur?

  • Offenbar werden Prozesse gestartet von einem daemon. (Nach Kill laeuft wieder ein prozess mit anderer PID)

    Ich bin mir nicht sicher, ob das wirklich so ist, oder ob auch da ein Missverständnis vorliegt.


    @sasatt: Kannst Du das mal bestätigen oder widerlegen? Wenn Du unmittelbar nach dem kill des hängenden Prozesses noch mal den fuser-Aufruf startest, wie ist dann die Ausgabe?


    Hast Du mal versucht, te923con mit der Option "-D" (debug output) zu starten?

  • Manul du hast vollkommen Recht.


    Nach dem kill sieht es so aus als wäre Alles ok ( Der hängende Prozeß wurde beendet - und der Pi Prompt ist wieder verfügbar - fuser Aufruf liefert keine Ausgabe ! )


    Beim nächsten Aufruf von te923con oder te923con -D ( liefert nur [DEBUG] VER 0.6.1 ) hängt es wieder, nur mit anderer PID.


    Wenn es zu Anfang funktioniert, gibt es dann ohne Parameter ( Hänger beim 7. ) oder mit -s ( Hänger beim 7. ) oder strace -f ( Endlosschleife beim 8. Auruf) das Problem.


    Ich kann auch mit -d den ganzen internen Speicher mit über 200 Zeilen ausgeben lassen ( hab ich bisher nicht siebenmal probiert weil dauert sehr lange )

    2 Mal editiert, zuletzt von satsatt ()

  • Der Zustand des USB ports/Schnittstelle ist offensichtlich nach dem kill nicht der gleiche wie nach einem reboot, obwohl ja kein Prozeß mehr darauf zugreift , denn es kommt sofort "Error while setting configuration (-16)" beim Zugriffsversuch.


    Mir scheint es so, als ob vorhergehenden usb configuration Aufrufe irgendwo gespeichert werden und dann beim 7.-8. mal kein Platz mehr im Speicher ist oder wahrscheinlicher der/die vorhergehende/n Zugriff/e nicht korrekt beendet wurde/n "Device or resource busy" .


    Code
    1. open("/dev/bus/usb/001/002", O_RDWR) = 3
    2. ioctl(3, USBDEVFS_GETDRIVER, 0xbe81cff8) = 0
    3. ioctl(3, USBDEVFS_IOCTL, 0xbe81d0e8) = 0
    4. ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbe81d0fc) = -1 EBUSY (Device or resource busy)
    5. write(2, "Error while setting configuratio"..., 41Error while setting configuration (-16).
    6. ) = 41
    7. exit_group(1) = ?
    8. +++ exited with 1 +++

    5 Mal editiert, zuletzt von satsatt ()

  • Vergleich von strace -f te923con.


    Links Fehlerhaft-Abbruch ( nach siebentem Aufruf) / Rechts normaler Aufruf mit Ergebnisrückgabe

  • @Rasp-Berlin


    meine Versuche mit journalctl -xe

    Ich finde nur
    interface 0 claimed by usbfs while 'te923con' sets config #1


    Zu diesem Fehler gibt es massig Fundstellen im Netz zu allen möglichen Geräten (Scanner, Drucker usw.) mit der gleichen Symptomatic ( es funktioniert ein paarmal und dann nicht mehr ). Eine Lösung konnte ich bisher nicht finden.

    2 Mal editiert, zuletzt von satsatt ()

  • [Aus /boot/overlays/README]

    Name: dwc-otg

    Info: Selects the dwc_otg USB controller driver which has fiq support. This

    is the default on all except the Pi Zero which defaults to dwc2.

    Load: dtoverlay=dwc-otg

    Params: <None>


    Vllt. lässt sich mit einem "dtoverlay=dwc-otg" in /boot/config.txt der dwc-otg Treiber auch beim Pi-Zero verwenden.


    Servus !

    Wer nichts weiß, muss alles glauben.

  • RTFM danke, ich hab es in config.txt hinzugefügt aber mit einer anderen SD card festgestellt, daß sowieso schon dwc_otg geladen wurde.

    Code
    1. pi@pizero2:~ $ lsusb -t
    2. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    3. |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=, 1.5M

    Einmal editiert, zuletzt von satsatt ()

    • sudo nano /etc/udev/rules.d/99-te923.rules
     ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801", MODE="0660", GROUP="plugdev", RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind

    Da könnte ein Fehler in der Anleitung sein, sodass der RUN Befehl ins /dev/null echoed.


    Wo, und ob das Hochkomma vom echo aufgelöst werden soll, weiss ich nicht. Das kann auch in der POSIX-sh Shell irgendwas besonderes bedeuten

    Die RUN="Anweisung gehört mMn aber mit einem Gänsefüsschen abgeschlossen".


    Ich würde einmal

    ,RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind ’"

    probieren. (zuerst ein Hochkomma ’ dann ein Gänsefüsschen ")



    Servus !

    Wer nichts weiß, muss alles glauben.

    Einmal editiert, zuletzt von RTFM ()

  • Entschuldigung - mein Typo nur hier im Forum.

    Richtig

    ATTRS{idVendor}=="1130", ATTRS{idProduct}=="6801", MODE="0660", GROUP="plugdev", RUN="/bin/sh -c 'echo -n $id:1.0 > /sys/bus/usb/drivers/usbhid/unbind'"


    scheint auch zu funktionieren denn es wird kein HID Driver gemeldet.


    /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M

    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=, 1.5M