Nach ein paar Tagen alle USB Geräte weg

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo zusammen,

    ich boote meinen Raspberry von einer SSD am USB3 Port, was auch sehr schön funktioniert. Zusätzlich habe ich noch einige serielle Geräte daran, teils auch über einen Hub. Alles funktioniert so 3-4 Tage wunderbar, bis dann plötzlich alle USB Geräte futsch sind, sowohl unter lsusb als auch die ttyUSBx unter /dev/

    lsusb

    Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb /s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    und

    ls -l /dev/tty

    tty tty17 tty26 tty35 tty44 tty53 tty62

    tty0 tty18 tty27 tty36 tty45 tty54 tty63

    tty1 tty19 tty28 tty37 tty46 tty55 tty7

    tty10 tty2 tty29 tty38 tty47 tty56 tty8

    tty11 tty20 tty3 tty39 tty48 tty57 tty9

    tty12 tty21 tty30 tty4 tty49 tty58 ttyprintk

    tty13 tty22 tty31 tty40 tty5 tty59 ttyS0

    tty14 tty23 tty32 tty41 tty50 tty6

    tty15 tty24 tty33 tty42 tty51 tty60

    tty16 tty25 tty34 tty43 tty52 tty61

    nach einem Reboot ist dann alles wieder da:

    lsusb

    Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge

    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

    Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

    Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

    Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub

    Bus 001 Device 004: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub

    Bus 001 Device 003: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC

    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub

    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    und

    ls -l /dev/tty

    tty tty11 tty15 tty19 tty22 tty26 tty3 tty33 tty37 tty40 tty44 tty48 tty51 tty55 tty59 tty62 tty9 ttyUSB1

    tty0 tty12 tty16 tty2 tty23 tty27 tty30 tty34 tty38 tty41 tty45 tty49 tty52 tty56 tty6 tty63 ttyprintk ttyUSB2

    tty1 tty13 tty17 tty20 tty24 tty28 tty31 tty35 tty39 tty42 tty46 tty5 tty53 tty57 tty60 tty7 ttyS0

    tty10 tty14 tty18 tty21 tty25 tty29 tty32 tty36 tty4 tty43 tty47 tty50 tty54 tty58 tty61 tty8 ttyUSB0

    also eben die ganzen USB Geräte, auch unter ttyUSBx

    ich habe das Problem genau seit dem Umstieg von RasPi3/micro-SD auf RasPi4/SSD via USB. Was ist die Ursache und wie kann ich das Problem lösen ?

    Vielen Dank,

    Tom

  • Hallo, nein, keine "Undervoltage detected" - ich habe das originale Netzgerät. Der Hub hat sogar ein extra Netzgerät. Es verschwinden Geräte sowohl am Pi als auch am Hub, aber offensichtlich ist der Hub selbst noch da und die ssd am usb auch.

    das einzige, was ich im syslog finden kann:

    ftdi_sio ttyUSB0: failed to get modem status

    Kann man für einen ersten Test vielleicht usb neu starten ?

    2 Mal editiert, zuletzt von Darth Weber (13. Januar 2021 um 11:32)

  • aber offensichtlich ist der Hub selbst noch da und die ssd am usb auch.

    Wo siehst Du den Hub im ersten Teil bei der Ausgabe von lsusb? IMHO ist der weg. So sieht das bei meinem Test RPi4 aus, wenn nichts angehängt ist.

    Code
    stf@stf-desktop:~$ lsusb
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Wenn der Hub verschwindet, dann musst Du mal zu diesem Zeitpunkt in die logs sehen. Evt. stimmt ja mit dessen Stromversorgung etwas nicht. Hilft es, den Hub aus- und wieder einzustecken, wenn der weg ist?

    USB am RPi schalten geht so (aber Achtung, LAN ist bei dieser Version auch immer geschaltet).

    Aus:

    echo 0 | sudo tee /sys/devices/platform/soc/http://3f980000.usb/buspower >/dev/null


    Ein:

    echo 1 | sudo tee /sys/devices/platform/soc/http://3f980000.usb/buspower >/dev/null

  • Blödsinn, du hast natürlich Recht: Der 7port Hub verschwindet auch. Leider habe ich das Problem aber auch mit den USB Geräten, die DIREKT am Pi hängen - die sind dann auch futsch.

    Leider sehe ich zu dem Zeitpunkt nichts im log, was für mich auf diesen Ausfall hindeuten könnte.

  • das einzige, was ich im syslog finden kann:

    ftdi_sio ttyUSB0: failed to get modem status

    Kann man für einen ersten Test vielleicht usb neu starten ?

    Wie sind mit und ohne "USB-Geräte", die Ausgaben von:

    Code
    dmesg | grep -iE 'usb|xhc'

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Wie sind mit und ohne "USB-Geräte", die Ausgaben von:

    Code
    dmesg | grep -iE 'usb|xhc'

    ?

    Moin, zuerst mal mit allen USB Geräten:

    ohne USB Geräte stelle ich ein, wenn es wieder passiert ...

  • Heute morgen ist es wieder passiert und nun habe ich:

    das Schalten mit

    echo 0 | sudo tee /sys/devices/platform/soc/http://3f980000.usb/buspower >/dev/null

    klappt nicht, den Pfad gibt es überhaupt nicht auf meinem RasPi4

  • Wenn du dmesg mit der Option -T aufrufst, siehst du die lesbare Uhrzeit und Datum.

    Ich tippe mal auf eine kurzfristige Störung der Stromversorgung, oder Temperaturprobleme. :2cents:

    okay, das kann natürlich immer eine Ursache sein. Ich bekomme allerdings keine undervoltage Meldungen und die cpu-Temp ist um die 50°C, also auch eigtl. okay. Außerdem ist es komisch, dass die ssd aktiv bleibt.

    Kann das iwie im Zusammenhang mit dem Booten der SSD am USB3 hängen ?

    Was kann ich noch probieren ?

    Es wäre auch schon hilfreich, wie ich - außer per reboot - die USB Geräte wieder aktivieren kann.

  • Es wäre auch schon hilfreich, wie ich - außer per reboot - die USB Geräte wieder aktivieren kann.

    Wenn Du nach dem die USB-Geräte weg sind und ohne deinen PI zu rebooten, einen USB-Stick in deinen PI steckst, wird dieser erkannt bzw. kann dieser USB-Stick benutzt werden?

    Wie ist die Ausgabe von:

    Code
    lsblk

    wenn alles geht, die USB-geräte weg sind und mit einem nachträglich gesteckten USB-Stick?

    EDIT:

    ist das ein PI4 mit 8GB oder weniger? Denn der PI4/8GB hat eine "verbesserte Stromversorgung" mit einem "Switched-mode power supply".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (15. Januar 2021 um 11:01)

  • Ich glaube, ich habe die Ursache gefunden. Auf meiner SD Karte hatte ich immer einmal pro Woche ein dd Backup machen lassen - um beim Umzug auf die SSD schlicht nicht mehr dran gedacht.

    Ich weiß, dass das mit dem dd bei einem heißen System ne ziemliche Schlamperei ist - aber ich fand es immer ganz angenehm, aus dem img mal ne Datei ziehen zu können, das war auch 5 Jahre problemlos.

    Für die SSD war das aber natürlich zuviel. Seitdem ich diesen cron rausgeschmissen habe, habe ich das Problem nicht mehr. Allerdings scheint sich jetzt alle 1-2 Wochen das USB zu verschlucken, denn manchmal sind die Zuordnungen zu den ttyUSB1,2,3 zerwürfelt. Ich kenne das mit den udev regeln, aber dieser Effekt ist mir im laufenden Betrieb auch neu. Sowas kenne ich nur nach einem reboot.

    Ob das Booten von SSD/USB3 vielleicht doch nicht so optimal ist ?

  • Mist, das wars nicht. Heute morgen wieder das gleiche Phänomen. Es ist alles weg - bis auf die ssd. Nur ein reboot, und alles wieder da. Ich gehe jetzt wohl doch runter von der ssd auf die sd Karte, schade.

    Hat jemand nen Tip, wie ich mögichst einfach die ssd auf die sd schiebe ? Clonen wird ja schwierig, da die sd viel kleiner ist. Allerdings ist die ssd auch kaum belegt, also Platz würde reichen :-/

    Einmal editiert, zuletzt von Darth Weber (30. Januar 2021 um 08:16)

  • mögichst einfach die ssd auf die sd schiebe

    Das sollte mit dem Kopieren per rsync recht einfach auf die bereits angelegten Partitionen auf der µSD Karte zu erledigen sein.

    Was mir aufgefallen ist, Du hast gar nicht geschrieben, welches OS Du verwendest und welche Updates zu gemacht hast. Kannst Du das bitte mal noch nachholen?

  • Zitat

    Ist es immernoch die gleiche Fehlernummer im dmesg -T ?

    ja, immer noch einen Haufen -71 - ich habe aber das Gefühl, dass die kommen, wenn die USB Devices schon weg sind.

    Zitat

    Kommt denn ohne reboot überhaupt noch eine Ausgabe, im dmesg, wenn du ein USB-Gerät ab- und wieder anstöpselst ?

    konnte ich heute morgen nicht mehr testen, aber vielleicht gönne ich mir noch einen Absturz

    Zitat


    Was mir aufgefallen ist, Du hast gar nicht geschrieben, welches OS Du verwendest und welche Updates zu gemacht hast. Kannst Du das bitte mal noch nachholen?

    Stimmt, das war das ganz aktuelle raspbian Anschließend alles mit

    Code
    apt-get update
    sudo apt-get full-upgrade
    sudo rpi-update
    sudo rpi-eeprom-update

    aktualisiert:

    Code
    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="10"
    VERSION="10 (buster)"
    VERSION_CODENAME=buster
    ID=raspbian
    ID_LIKE=debian
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

    und die Bootreihenfolge angepasst. oder so, damit er ohne sd bootet. Genau weiß ich das nicht mehr. Mit dem Booten selbst hatte ich auch nie Probleme, habe jetzt ja jede Woche machen dürfen :-/

    Danke für den Tip mit rsync. Daran dachte ich auch schon, ist wahrscheinlich das einfachste.

  • sudo rpi-update

    Das ist nicht dein Ernst. Das solltest du wieder rückgängig machen.


    Es gibt so gut wie keinen Grund an einem laufenden System ein Firmware- und Kernel-Update mit "rpi-update" durchzuführen. Die Gefahr ist viel zu groß, dass danach das eine oder andere System nicht mehr richtig funktioniert.

    EDIT

    was sagt uname -a

    ?

  • sudo rpi-update

    Das solltest du wieder rückgängig machen.

    Nicht sollen, müssen. Hatten wir erst die Tage, dass einmal die Tastatur spann und ein anderes mal ähnliche Effekte wie bei Deinem Pi auftraten. Stelle die aktuelle Version des Kernels wieder her - oder installiere das System neu und lass in Zukuft die Finger weg von rpi-update.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!