Meine Erfahrung ist die, das die Kabel die mit einem Handy mitgeliefert werden eigentlich nur zum Laden geeignet sind.
Besorge dir ein neues Kable und versuche es dann noch einmal, alles andere ist raten ins Blaue.

  • sekret hat auf diesen Beitrag geantwortet.

    sekret Gibt es etwas, was ich noch prüfen könnte?

    Entschuldige die dumme Nachfrage.
    Ist denn am Smartphone die Datenverbindung freigeschaltet?

    Ich würde das Smartphone mittels USB-c Kabel mal mit einem zweiten Smartphone oder einem anderen Gerät mit USB-c verbinden, dann weiß man wenigstens schon mal, dass das Kabel und das Smartphone funktionieren.

    • Dirk und sekret haben auf diesen Beitrag geantwortet.

      tuxnix Ist denn am Smartphone die Datenverbindung freigeschaltet?

      Bei aktuellen Android-Versionen ist das tatsächlich gar nicht mehr so direkt nötig, bzw. möglich, da die seit längerem schon nur noch MTP unterstützen. Nach dem Einstöpseln also runterswipen und die Verbindungsart auf MTP oder "Massenspeicher" stellen.

      Am Computer dann: https://wiki.archlinux.de/title/MTP

      • tuxnix hat auf diesen Beitrag geantwortet.

        Dirk Bei aktuellen Android-Versionen ist das tatsächlich gar nicht mehr so direkt nötig

        Wir wissen doch gar nicht welche Lineage Version installiert ist und wie die Menueführung dort gestaltet ist.
        Mein Gedanke war denn auch einfach nur, dass man erst einmal eine funktionierende Anordnung benötigt, damit man damit den USB-c Anschluß des Notebooks testen kann.
        Man sollte schon mal Daten mit diesem Handy und dem Kabel übertragen haben. Zumindest grenzt dieses Vorgehen die möglichen Fehlerquellen ein.

        Hast du bei dem Schlappi noch andere USB3 Buchsen die funktionieren bzw ausprobiert?
        Wenn nicht, so könnte das am fehlendem Modul xhci_pci liegen.
        Manche PCs benötigen dafür noch eine separate Firmware upd72020x-fw aus dem AUR.
        Siehe auch hier: https://forum.archlinux.de/d/34309-mkinitcpio-zeigt-neue-fehler

        • sekret hat auf diesen Beitrag geantwortet.

          So, ich hab jetzt viel geschrieben und alles reingehauen, was ihr gefragt und vorgeschlagen habt und alles, was ich so weiß, zu wissen glaube oder an Ideen habe. Erschlagend, ich weiß, aber vielleicht klärt es sich so schneller.

          Gleich vorweg, ich hab auf dem Handy (Google Pixel 2) und meinem Tablet (Samsung Galaxy S6 Lite, das ich jetzt noch hinzugenommen habe und auch einen USB-C-Anschluss hat) LineageOS in Version 19.1 am Laufen. Ich nutze bei beiden die Version von der microG-Seite, weil ich das leider benötige. Aber das sollte hier nicht relevant sein.

          HansHiasl
          Danke für den Link! Für mich relevant scheinen die letzten Worte zu sein.

          Allerdings sind Geräte und Kabel, die auf Thunderbolt 3 ausgelegt sind, nicht mit USB 3.0- / USB-C-Buchsen kompatibel. Sie lassen sich zwar in den Slot einstecken, die Software läuft dann allerdings nicht.

          (Quelle: https://www.heise.de/tipps-tricks/Thunderbolt-und-USB-C-Wo-liegt-der-Unterschied-4662253.html)

          Vermutlich ist das Kabel an meiner Docking-Station auch auf Thunderbolt ausgelegt. Würde Sinn machen, weil darüber mein Laptop geladen werden und das Signal für den externen Bildschirm gehen soll. Davon gehe ich jetzt einfach aus, auch wenn mich dann dieser Adapter auf USB-A wundert. Ebenso gehe ich davon aus, dass das Kabel des MacBooks ein Thunderbolt-Kabel ist.
          edit: Wobei das dann doch heißen müsste, dass meine USB-C-fähigen Android-Geräte generell nicht mit diesen Kabeln funktionieren dürften, oder? Tun sie aber ja. Siehe weiter unten im Text. Oder ist es bei Thunderbolt 4 wieder anders?!

          Um diesen Anschluss gescheit testen zu können, muss ich also wohl ein explizites USB-C auf USB-C-Kabel kaufen oder einen USB-C-Stick usw. Richtig?

          josefine
          Diese Erfahrung kann ich tatsächlich nicht teilen, war bei mir noch nie so. Das Kabel, das dabei war, funktioniert. Ist aber eben ein USB-A auf USB-C, daher stecke ich das ja in den USB-A-Anschluss, welcher funktioniert.

          tuxnix
          Ich verbinde mein Handy immer mit adbfs, läuft bei mir besser als MTP. Aber letztlich ist das egal.
          Wenn ich das Smartphone mit aktivem ADB an den Thunderbolt hänge und dann MTP aktiviere, kommt folgende Ausgabe:
          $ udevadm monitor
          monitor will print the received events for:
          UDEV - the event which udev sends out after rule processing
          KERNEL - the kernel uevent
          ####### Hier stecke ich das Kabel in den Thunderbolt ein
          KERNEL[17737.128079] add /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          KERNEL[17737.134601] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          KERNEL[17737.134642] bind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17737.723283] add /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17737.724458] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          UDEV [17737.727281] bind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          ####### Hier schalte ich MTP ein
          KERNEL[17746.068413] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          KERNEL[17746.068866] unbind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          KERNEL[17746.068895] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17746.070114] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          UDEV [17746.071040] unbind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17746.071644] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          KERNEL[17746.785942] add /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          KERNEL[17746.792227] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          KERNEL[17746.794720] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.1 (usb)
          KERNEL[17746.794755] bind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17747.395423] add /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17747.396599] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          UDEV [17747.397348] add /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.1 (usb)
          UDEV [17747.398627] bind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          ####### Hier ziehe ich das Smartphone wieder ab
          KERNEL[17755.539389] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          KERNEL[17755.539419] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.1 (usb)
          KERNEL[17755.541350] unbind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          KERNEL[17755.541372] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17755.541614] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.1 (usb)
          UDEV [17755.541656] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0 (usb)
          UDEV [17755.542635] unbind /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)
          UDEV [17755.543337] remove /devices/pci0000:00/0000:00:14.0/usb3/3-6 (usb)

          Wenn ich das Smartphone an den USB-C-Anschluss hänge, kommt keinerlei Ausgabe und am Handy taucht die Möglichkeit, MTP zu aktivieren, auch gar nicht erst auf. Es kommt keinerlei Datenverbindung zustande. Das Smartphone wird aber geladen.
          Das Smartphone funktioniert also und auch mit diesem Kabel des MacBooks.

          Mit meinem Tablet ist es sehr ähnlich. Mit dem Thunderbolt am Laptop funktioniert alles, beim USB-C kommt keine Datenverbindung zustande. Zusätzlich wird es hier aber auch nicht geladen. Wahrscheinlich ist die Stromstärke zu gering. Es lädt auch an den USB-A-Anschlüssen nicht.

          Jetzt wird es aber spannend!
          Zwischen dem Tablet und dem Smartphone kommt tatsächlich eine Datenverbindung zustande mit dem Kabel des MacBooks, wenn ich die beiden verbinde. Ich hatte das nie ausprobiert und erst durch deinen Beitrag kam ich überhaupt auf die Idee!

          Zwischenfazit
          Beide Android-Geräte kommen mit dem Kabel des MacBooks klar. Beide können mit dem Laptop über den Thunderbolt-Anschluss eine Verbindung aufbauen und ebenso untereinander. Das heißt für mich, dass das Kabel USB-C-fähig ist. Korrekt?
          Beide Android-Geräte bleiben aber stumm, wenn ich das MacBook-Kabel mit dem USB-C-Anschluss des Laptops verbinde. Kann ich daraus dann schon logisch schließen, dass der USB-C-Anschluss am Laptop tot ist? Nach meiner Logik und dem, was ich von HansHiasls Link gelernt hab, ist das so. Aber ich lasse mich gern eines Besseren belehren!

          Greg
          Ja die andere USB3-Buchse im USB-A Baustil am Laptop tut(, die USB2-Buchse auch), darüber kommt eine Datenverbindung zustande und das Handy lädt auch. Beim Tablet ebenso, allerdings wird es nicht gescheit geladen, wahrscheinlich wegen zu geringer Stromstärke (der Ladezustand wird mehr oder weniger gehalten)

          Diese Firmware hatte ich bereits installiert, eben wegen diesen Warnungen von mkinitcpio. Ob ich sie brauche, weiß ich aber nicht.

          Das Modul xhci_pci ist geladen, siehe u.a. unter
          $ dmesg | grep xhci
          [16798.515001] usb 3-6: new high-speed USB device number 7 using xhci_hcd
          [17691.628932] usb 3-6: new high-speed USB device number 8 using xhci_hcd
          [17736.845934] usb 3-6: new high-speed USB device number 9 using xhci_hcd
          [17746.706007] usb 3-6: new high-speed USB device number 10 using xhci_hcd
          [17766.839484] usb 3-6: new high-speed USB device number 11 using xhci_hcd
          [18209.862722] usb 3-6: new high-speed USB device number 12 using xhci_hcd
          [18225.472786] usb 3-6: new high-speed USB device number 13 using xhci_hcd
          [18292.473307] usb 3-6: new high-speed USB device number 14 using xhci_hcd
          $ lsmod | grep xhci
          xhci_pci 20480 0
          xhci_pci_renesas 24576 1 xhci_pci

          Oh!
          Deutet das geladene Modul xhci_pci_renesas darauf hin, dass ich diese Firmware also doch benötige?
          Also mkinitcpio läuft damit sauber durch und spuckt keine Warnung diesbezüglich aus. Hier ein Auszug:
          $ mkinitcpio -P
          […]
          ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
          -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
          ==> Starting build: 6.0.6-arch1-1
          -> Running build hook: [base]
          -> Running build hook: [udev]
          -> Running build hook: [autodetect]
          -> Running build hook: [keyboard]
          -> Running build hook: [modconf]
          -> Running build hook: [block]
          -> Running build hook: [keymap]
          -> Running build hook: [numlock]
          -> Running build hook: [encrypt]
          ==> WARNING: Possibly missing firmware for module: qat_4xxx
          -> Running build hook: [lvm2]
          -> Running build hook: [filesystems]
          -> Running build hook: [fsck]
          -> Running build hook: [shutdown]
          ==> Generating module dependencies
          ==> Creating zstd-compressed initcpio image: /boot/initramfs-linux.img
          ==> Image generation successful
          […]

          Also ich gehe jetzt mal davon aus, dass ich diese Firmware benötige und dass sie geladen wird. Ich schmeiße sie mal runter und schaue, welche Änderungen sich ergeben.

          Noch eine Idee
          Gibt es eine Möglichkeit, unter diesen verschiedenen offensichtlich erkannten Geräten mit Nummer 7 bis 14 (siehe dmesg-Ausgabe oben) herauszufinden, welche tatsächlichen Anschlüsse das letztlich sind?

          Meine Idee dazu ist gerade lspci -vvv zu nutzen. Wenn ich da nach xhci suche, finde ich diese beiden Einträge:
          $ lspci -vvv
          […]
          00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01) (prog-if 30 [XHCI])
          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
          Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
          Latency: 0
          Interrupt: pin ? routed to IRQ 129
          IOMMU group: 5
          Region 0: Memory at 601f560000 (64-bit, non-prefetchable) [size=64K]
          Capabilities: [70] Power Management version 2
          Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
          Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
          Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
          Address: 00000000fee00318 Data: 0000
          Capabilities: [90] Vendor Specific Information: Len=14 <?>
          Capabilities: [b0] Vendor Specific Information: Len=00 <?>
          Kernel driver in use: xhci_hcd
          Kernel modules: xhci_pci]
          […]
          00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20) (prog-if 30 [XHCI])
          Subsystem: CLEVO/KAPOK Computer Device 51a1
          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
          Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
          Latency: 0
          Interrupt: pin A routed to IRQ 131
          IOMMU group: 6
          Region 0: Memory at 5ac00000 (64-bit, non-prefetchable) [size=64K]
          Capabilities: [70] Power Management version 2
          Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
          Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
          Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
          Address: 00000000fee00358 Data: 0000
          Capabilities: [90] Vendor Specific Information: Len=14 <?>
          Capabilities: [b0] Vendor Specific Information: Len=00 <?>
          Kernel driver in use: xhci_hcd
          Kernel modules: xhci_pci
          […]

          Der erste Eintrag scheint der Thunderbolt-Anschluss zu sein, der zweite der USB-C, der ja laut Hersteller ein USB-C 3.2 Gen2 ist.
          Er wird also erkannt. Soweit, so gut. Bzw. so verwirrend… Laut dmesg waren es doch viel mehr Geräte, die den xhci_hcd nutzen?1

          Fazit
          Ich wollte mir ja eh mal für nen USB-C-fähigen USB-Stick zulegen, den ich mit meinem Laptop und auch meinem MacBook verwenden kann. Das MacBook hat nur USB-C (bzw. Thunderbolt), da taugt keiner meiner Sticks.
          Dann ramme ich den in meinen USB-C-Anschluss und wenn da dann auch nix passiert, dann kann ich es wohl so sagen, dass der Anschluss kaputt ist und drauf hoffen, dass der als Garantiefall durchgeht.

          Eine letzte Frage
          Ist es denkbar, dass ein USB-C-Anschluss kaputt geht, wenn man das Kabel einer Dockingstation, mittels welchem der Laptop auch geladen wird, wo also potenziell eine Spannung anliegt, versehentlich in diesen USB-C-Anschluss reinsteckt? Das ist mir 1-2x passiert. Die Dockingstation benutze ich, seit ich den Laptop habe und weil die beiden Anschlüsse direkt nebeneinander sind, war das wohl nicht zu vermeiden. Andererseits wäre das ja fatal, wenn dadurch der Anschluss beschädigt würde!
          Vermutlich liegt da anfangs keine Spannung an, oder? Ich vermute, dass die beiden verbundenen Geräte zuerst kommunizieren und dann, wenn klar ist, dass der Anschluss am Laptop auch zum Laden taugt, also ein Thunderbolt ist, dass erst dann die Spannung angelegt wird.
          Aber das ist bloß eine Vermutung, ich kenne mich (wie man lesen konnte) mit diesen Anschlüssen kaum aus.

          Danke fürs Lesen und sorry für den langen Text!

          • schard hat auf diesen Beitrag geantwortet.

            Der neue lsplug Befehl könne da hilfreich sein.

            Mit lsplug -r -p lassen sich die USB-Geschwindigkeit und der maximale Stromverbrauch, mit dem sich ein Gerät beim Host anmeldet, zusätzlich anzeigen.

            • sekret hat auf diesen Beitrag geantwortet.

              sekret Ist es denkbar, dass ein USB-C-Anschluss kaputt geht, wenn man das Kabel einer Dockingstation, mittels welchem der Laptop auch geladen wird, wo also potenziell eine Spannung anliegt, versehentlich in diesen USB-C-Anschluss reinsteckt?

              Bei genügend Ampère, sicher.
              Ich würde das Gerät allerdings an den Hersteller zurücksendenund Garantie geltend machen.

              • sekret hat auf diesen Beitrag geantwortet.

                schard
                Es schreit förmlich danach, ja.

                tuxnix
                Ich hab noch weiter rumprobiert, mit lsplug, mit lshw usw. Letztlich ist das Ding aber einfach tot.

                Einen letzten Versuch möchte ich noch wagen über ein Live-Medium. Vielleicht hängt es ja doch irgendwie mit Arch zusammen, auch wenn ich das echt nicht glaube. Und eben über einen USB-C-fähigen Stick, möchte ich mir eh zulegen.

                Zum Glück habe ich ja das MacBook, auch wenn ich damit echt die Krise kriege. Aber besser als nichts! 😉

                Es kann natürlich nichts schaden mal ein Speicher Medium dran zu hängen.
                Ich denke aber auch, das Ding ist einfach tot.
                Für die Reklamation beim Hersteller gäbe es da noch ein passendes (Monty) Python Skript.

                mein nokia schlau phon hat auch einen usb-c anschluß, der hat aber eine tücke: je nach dem welche seite vom stecker oben ist, lädt er , oder nicht, das gilt auch für die datenübertragung.
                wenns nicht geht, würde ich den stecker abziehen, und 180′ gedreht wieder einstecken.

                • sekret und Dirk haben auf diesen Beitrag geantwortet.

                  brikler
                  Das ist ja mal sehr merkwürdig!

                  Hab es eben aber trotzdem getestet. Kein Unterschied.

                  brikler Leicht OT: Das hatte ich bei meinem Pixel 2 auch. Hat sich herausgestellt, dass das Kabel 'ne Macke hatte. USB-Kabel sind ja inzwischen mehr als nur dumme Layer-1-Verbindungen.

                  ein Jahr später

                  So, ca 1 Jahr später möchte ich das Thema hier abschließen. Ich habe den Laptop jetzt doch nicht zum Hersteller zurückgeschickt, einfach weil ich das Ding sehr regelmäßig brauche. Das war im Nachhinein auch ok, denn:

                  Plötzlich funktioniert dieser Anschluss… Ich habe es eben einfach nochmal probiert, kein Plan warum, und er tut ganz normal, auch über die Kabel von vor einem Jahr.

                  Kann das letztlich an Linux gelegen haben? Also hat der Arch'sche Kernelbauer da jetzt etwas an der Konfiguration geändert, was das bisher verhindert hat?

                  Ich bin einigermaßen verwirrt, aber gut, das Thema ist hiermit für mich abgeschlossen. Falls aber jemand eine Idee hat, wie das sein kann, gerne her damit.

                  Ich gratuliere. Danke für die Rückmeldung hier.
                  Klar kann das sein. Frag doch interessehalber einfach nocheinmal bei Tuxedo an.
                  Die müssen am Besten wissen, was sie da verbaut haben und was davon Kernelunterstützung hat/ bzw. noch nicht hatte.
                  Falls bei einem Tuxedo Notebook noch einmal so etwas auftritt würde ich auch mal dem Tuxedo eigenen OS testweise eine Chance geben. Mancher Hack von einem Hersteller braucht auch etwas Zeit bis er dann in den mainline-kernel aufgenommen wird und dann später bei Arch Linux landet.

                  Mal analog zur Anschauung: Hier versuchen Leute alle Funktionen vom USB Anschluß eines Smartphones in den Kernel einzubringen, was aber erst teilweise gelungen ist.
                  Wenn es dann gelingt, wird dann zuerst postmarketOS damit betrieben und später landet der Patch dann, wenn er ausgereift ist, im Mainlinekernel.

                  Ja ich muss gestehen, dass der Tuxedo-Support mir damals empfohlen hatte, dass ich deren OS als Live-System teste. Wahrscheinlich wusste der Support da etwas, was ich nicht für möglich hielt. Ich hielt das für so ein standardmäßiges Geschwätz… Tja, wieder was gelernt! Naja, ich hab den Port bisher nie benötigt und benötige ihn weiterhin nicht. Daher ist das alles in keinster Weise tragisch oder sonst was. Ich hätte das aber niemals für möglich gehalten, da ich USB (egal welche Version) für Standard halte, der im Linux-Kernel ja sogar implementiert ist, bevor es Hardware gibt…

                  • tuxnix hat auf diesen Beitrag geantwortet.

                    sekret da ich USB (egal welche Version) für Standard halte

                    Es steht da USB drauf, damit du weißt welchen Stecker du in die Buchse stecken darfst.
                    Dann gibt es einen Standard der beschreibt was welchses USB leisten muss damit es USB heißen darf.
                    Und dann gibt es von Herrsteller zu Hersteller und von Gerät zu Gerät sehr unterschiedliche Bauteile die das leisten sollen was das jeweilige USB alles können soll.
                    Und für diese elektronischen Bauteile braucht es jeweils die passende Software, sonst tun die nichts.

                    "Das ist doch USB, ich hab den Stecker drinn, das muss doch jetzt..." ist die Verbraucherseite. 😉
                    Je nachdem was Tuxedo einkauft und verbaut, wird das dann schon vom kernel getrieben oder sie müssen es selber stricken.
                    Bei den ARM Entwicklerboards ist das fast der Normalzustand, dass die verlötete Hardware erst nach Jahren nach dem Kauf voll funktionsfähig ist. Pine baut fleißig devices und die Community soll dann selber schauen wie sie das Zeug zum Laufen bekommen. Ich hatte mal ein Cubiboard das funktioniert bis heute noch nicht richtig.

                    Sehr interessant, danke! Da war ich dann wohl bisher voll auf der Verbraucherseite 😉 Erlaube ich mir aber auch, in die Untiefen von allem, was Computertechnik betrifft, werde ich in diesem Leben nicht mehr aufsteigen.

                    • tuxnix hat auf diesen Beitrag geantwortet.

                      sekret in die Untiefen von allem,

                      ... werde ich auch in diesem Leben nicht mehr vordringen können.
                      Ich wollte dir auch nur eine plastische Vorstellung davon geben wie die Abläufe in der Entwicklung sind und wie es kommen kann, dass 'ein toter Papagei' plötzlich putz munter wird. 😉