Geteiltes Leid ist halbes Leid?

Mit diesem Beitrag möchte ich eine Geschichte und damit verknüpfte Gedanken niederschreiben – oder auch: los werden – welche mich seit längerer Zeit beschäftigt. Soviel vorweg: Es wird kein Gute-Laune-Beitrag, denn es geht um das Thema Depression.

Knapp jeder fünfte Deutsche erkrankt im Laufe seines Lebens an einer depressiven Störung (Quelle). Umso erstaunlicher ist es, wie wenig diese Krankheit im Bewusstsein unserer Gesellschaft ist, und noch mehr, wie schwer es ist, Hilfe zu finden. Um meine Erfahrungen als Außenstehender soll es im Folgenden gehen.

Kontext:
Eine Kollegin ist, so lange ich sie kenne, etwas … kompliziert. Soziale Situationen überfordern sie manchmal. Ihre Entscheidungen und ihr Handeln folgen Teils einer ganz eigenen Logik, die für Außenstehende nicht immer nachvollziehbar ist. Dazu kommen, in sehr ausgeprägter Form, Ehrgeiz und hohe Ansprüche an sich selbst. In letzter Konsequenz führt dies zu extremen Stresssituationen, Überforderung, Ängsten und Verzweiflung.

Ich habe meist ein offenes Ohr für meine Mitmenschen und kann mich schwer abwenden wenn ich bemerke dass es ihnen schlecht geht. So kam es, dass ich irgendwann versuchte, meiner Kollegin aus einem Stimmungstief heraus zu helfen, woraus sich nach und nach eine Vertrauensbeziehung entwickelte. Leider war mein seelischer Beistand nicht genug, die Situation eskalierte zunehmend. Auf Phasen relativer Ruhe folgten, oft ausgelöst durch externe Stressfaktoren, immer heftigere Zusammenbrüche. Und irgendwann dann das erste Mal laut ausgesprochene Suizidgedanken.

Exkurs: Suizid
Der Gedanke an Suizid ist für meinen Verstand so skurril, so abwegig, wie es überhaupt nur ein Gedanke sein kann. Ich kann begreifen, dass unheilbar degenerativ erkrankte Menschen oder solche in vergleichbaren Ausnahmesituationen den Wunsch nach einem selbstbestimmten, schmerzlosen Tod in Würde haben. Aber davon abgesehen? Das überschreitet die Grenzen meines Verstandes.

Dass meine Kollegin diese Gedanken äußerte, bewirkte zwei Dinge. Ab diesem Zeitpunkt war für mich vollkommen klar, dass sie professionelle Hilfe braucht. Zugleich wollte, konnte ich sie nicht Stich lassen. Ich fühlte mich verantwortlich. Und damit auch völlig überfordert. Überfordert damit, in einer Situation gefangen zu sein, die ich nicht selbst kontrollieren konnte. Ich wusste um ihren Zustand, konnte aber lange mit niemandem darüber reden. Ich war zum Zusehen verdammt, konnte doch nur sie selbst die Entscheidung treffen, professionelle Hilfe aufzusuchen.

Hilfe zu finden erwies sich, nachdem der Entschluss endlich gefasst war, dann als unglaublich schwierig. Im Hinblick darauf, dass sowohl die erkrankte Person als auch Angehörige und Freunde mit der Situation überfordert sind, wäre es wünschenswert eine Anlaufstelle zu haben, die geeignete Angebote kennt, vermittelt und den Prozess organisatorisch begleitet. Tatsächlich wurde meine Kollegin, nachdem sie sich an ihren Hausarzt wandte, an eine Psychiaterin verwiesen. Diese riet, im Hinblick auf eine drohende Depression, dringend zu eine psychotherapeutischen Behandlung – und schickte meine Kollegin mit einer Liste von ebensolchen Therapeuten wieder nach Hause. Einen Therapieplatz zu erhalten ist ein Glücksspiel. Selbst einen Therapeuten nur ans Telefon zu bekommen ist bei telefonischen Sprechzeiten von einmal wöchentlich 15 oder 30 Minuten eine Herausforderung, insbesondere für einen berufstätigen Menschen mit einer psychischen Erkrankung!

Nach einer weiteren Phase relativer Ruhe folgte dann, die nächste Eskalationsstufe: Meine Kollegin fügte sich wiederholt gezielt Schnittwunden an den Unterarmen zu. „Nur“ oberflächlich, aber das genügte für mich. Abwarten war ausgeschlossen, Hilfe war so schnell wie möglich nötig. Wie schlecht es Ihr ging, nahm sie dabei gar nicht wahr. Ich dachte darüber nach, sie in eine Notaufnahme zu bringen, aber sie verneinte in irgend einer Form ein Notfall zu sein, das wären ja nur ernsthaft kranke Menschen. Viel schlimmer anzusehen als die körperlichen Wunden war ihr seelischer Zustand. Ihr Verstand quälte sie – und ich fühlte ihren Schmerz, litt mit ihr.

Schließlich suchten wir eine Beratungsstelle auf. Das Gespräch war vor allem unter einem Gesichtspunkt wertvoll: Ich erfuhr von einer psychiatrischen Ambulanz als mögliche Anlaufstelle für Notfälle. Nach weiteren Schnitten und einem eigentlich schon lange überfälligen Gespräch mit dem Arbeitgeber brachte ich meine Kollegin schließlich in genau diese Ambulanz.

Und an dieser Stelle endet die Geschichte, denn auch wenn erste Schritte getan sind: Meine Kollegin hat noch einen langen Weg vor sich. Nach stationärem Aufenthalt arbeitet sie wieder, aber die Therapie läuft weiter. Mit der Rückkehr in den Alltag ist auch ein Teil der Verantwortung wieder zu mir zurück gekehrt, welche ich in der Ambulanz abgeben konnte. Gleichwohl ist die Situation nun eine andere. Ich muss keine Entscheidungen mehr darüber fällen, was Richtig für meine Kollegin ist, oder was andere erfahren dürfen. Ich muss diese Last nicht mehr alleine tragen.

Und hoffentlich kann ich eines Tages auch meine Flügel als „Schutzengel“ an den Nagel hängen und einfach nur ein Freund für sie sein. Denn einfach nur eine Kollegin ist sie schon lange nicht mehr für mich.

Mind the Gap: MTU-Probleme mit VPN

Dieser Beitrag hat mehr den Charakter einer Gedankennotiz, aber vielleicht hilft er ja auch anderen weiter …

Die die Maximum Transmission Unit (MTU) ist ein Parameter mit dem man bei der Netzwerkkonfiguration in der Regel nicht viel zu tun hat. Ich habe aber in der Vergangenheit die Erfahrung gemacht, dass es durchaus sinnvoll sein kann, sich die MTU-Konfiguration näher anzusehen wenn VPN-Tunnel sich komisch verhalten und SSH-Verbindungen plötzlich einfrieren, speziell wenn sich der Inhalt der Konsole in größerem Umfang ändert. Die MTU manuell zu reduzieren führt dann in der Regel dazu, dass alle Probleme schlagartig verschwinden. Unter Linux kann (ggf. für das entsprechende Netzwerkinterface angepasst) das folgende Kommando da Abhilfe schaffen.

ip link set dev tun0 mtu 1200

Der Wert von 1200 sollte in der Regel völlig ausreichen, kann ggf. aber auch noch weiter reduziert werden.

Renesas USB 3.0 Controllers vs. Linux

USB 3.0 extension cards based on Renesas uPD720202 chipset appear to be somewhat problematic when Linux is used as operating system. This may also apply to other Renesas USB chipsets as well. This post is about the difficulties I experienced when trying to use such an extension card with Linux, and a tool to upload required firmware to the chipset.

Preface

The uPD720202 chipset requires additional firmware to operate. It must be either uploaded by the driver during initialization, or can be stored on an external EEPROM. Its open to the vendor to choose one of these options. For the first case, there exists a patch for the Linux kernel driver for this chipset to support uploading the firmware image at boot time. But apparently, this patch never made it into the kernel and I have not found the firmware image in the linux-firmware repository. Apparently, at least some of the cards equipped with an EEPROM do initially not function properly with Linux, and maybe even with Windows. They are either shipped with no firmware at all, or at least with outdated firmware.

Long story short: My card simply did nothing but pause the boot process for about 30 seconds until the driver gave up, complaining about being unable to setup the card and quitting with exit code -110:

Feb 5 19:43:18 atom kernel: [ 33.285715] xhci_hcd 0000:02:00.0: can’t setup: -110
Feb 5 19:43:18 atom kernel: [ 33.285944] xhci_hcd 0000:02:00.0: USB bus 6 deregistered
Feb 5 19:43:18 atom kernel: [ 33.286142] xhci_hcd 0000:02:00.0: init 0000:02:00.0 fail, -110
Feb 5 19:43:18 atom kernel: [ 33.286199] xhci_hcd: probe of 0000:02:00.0 failed with error -110

Dead ends …

So the question is: With which kind of extension card am I dealing with? The datasheet of the uPD720202 chipset provides information about some useful registers. The „External ROM Access Control and Status Register“ suggests that my card is equipped with EEPROM, since the „External ROM Exists“ bit is set (in fact, it is the only bit set after boot):

root@atom:~# setpci -s 02:00.0 f6.w
8000

So my first take was to update the firmware of the chipset. Sadly, I was unable to find any working tool which would enable me to upload the firmware into the EEPROM for Linux, even though the process itself is documented quite well in the datasheet of the chipset. In the end, I grabbed an old harddisk and installed Windows on it to be able to install the firmware which was kindly shipped with the driver disk. Pretty much hassle to be able to use a extension card … but at least, it works now? Well, not exactly. The card stops to work with Linux after the power supply is removed. Either the Windows driver does some magic to initalize the card, or the card is not really equipped with an EEPROM and needs to get a firmware upload at boot time?

… and working solutions quirks

The firmware upload functionality works independently from the firmware EEPROM, according to the chipset datasheet. More interestingly, uploaded firmware takes precedence over the firmware stored in the EEPROM. What if this could be done with Linux, too? During my research, I already stumbled upon a blog post discussing the possibility to interface with the chipset using „setpci“. Furthermore, some source code posted in the comments section claimed to implement the EEPROM read and write procedures outlined in the datasheet. This code, whose unknown author I would like to thank a lot, turned out to be a good starting point. I did some major refactoring, cleanup and bugfixing and implemented the firmware upload functionality according to the datasheet. And this did the trick! After uploading and re-initializing the driver, the card became fully functional.

upd72020x-load

The tool for uploading the firmware is called upd72020x-load and available from a GitHub repository. Refer to the README.md file for usage information. For my purposes, I also added the script check-and-init which scans for all uninitialized uPD720202 devices and tries to upload the firmware to them. I integrated the script into the boot process so I do not have to think about uploading the firmware at all. The firmware itself is not included, but it is easily possible to extract the firmware image from the updater for Windows.

upd72020x-load works for me, however: Use it at your own risk!

Closing Remarks

My card is equipped with the uPD720202 chipset. There exists a different version of this chipset, called uPD720201, which differs only in the number of USB ports provided. Especially, the procedures required to upload the firmware or to read and write the EEPROM are identical. However, i did not test upd72020x-flash with any of those extension cards. In any case, please report any bugs you might encounter.

Sofern nicht anders angegeben, stehen die Inhalte dieses Blogs unter der Lizenz
Creative Commons BY-NC-ND 3.0 Deutschland
Creative Commons Lizenzvertrag