Beiträge von sunnygerald

Danke für den Hinweis. Ich werde dies sicherlich in Betracht ziehen, wenn es da nach einigen Tagen/Wochen keine Lösung gibt. Aber für die nächsten Tage/Wochen will ich noch nicht glauben, dass dies beim SLES-Kernel wirklich 'works as designed' sein soll ... (es kann/darf nicht sein, dass man im laufenden Betrieb kein swap device mehr inaktiv schalten kann... Sonst bricht gerade eine Welt für mich zusammen )

Zitat

weil das RAM voll ist.

nee. Ist es ja nicht (mehr). In der Situation (siehe swapon --show) waren 4 MB von 8 GB swap belegt. Von dem 32 GB RAM waren nur ~5 GB belegt. Die 4 MB wurden so ca bei 90% RAM Auslastung genutzt. An den 32 GB war ich nie dran..

Nachdem mein System (Laptop, OpenSuse Leap 16.0) sporadisch beim Herunterfahren immer mal wieder hängen blieb, konnte ich nun (endlich) das Problem einkreisen:

Immer wenn swap space benutzt ist, ist eine saubere Deaktivierung der (swap) Partition nicht mehr möglich.

rhea:~ # swapon --show
NAME           TYPE      SIZE USED PRIO
/dev/nvme0n1p8 partition   8G 4,6M   -2 
rhea:~ # swapoff /dev/nvme0n1p8

Der swapoff endet nicht. Die Lüfter laufen auf Hochtouren. System ist 99% busy

rhea:~ # ps aux | grep swapoff
root        5406 99.7  0.0   7112  4740 pts/0    R+   11:57   4:21 swapoff /dev/nvme0n1p8

Im Journal ist nichts verdächtiges was auf einen IO Fehler hinweisen würde. Es wird keine LUKS/Verschlüsselung für die swap Partition benutzt. Aktuelle Patches sind eingespielt.

Habe das Problem auch noch auf einem weitere Rechner.

Ist das ein Kernel-Bug oder was könnte es sonst noch sein?

Ich komme mal wieder zum Ausgangsproblem zurück.

Es gibt nun ein Update für mariadb (11.8.6-160000.2.1) was wohl das Problem lösen sollte (Fixes crash in information_schema.table_constraints when --skip-grant-tables (bsc#1263153))

Leider lässt sich dies aber wegen Abhängigkeitsproblemen bei mir aber nicht einspielen ("das installierte mariadb-11.8.5-160000.3.1.x864_64 erfordert 'user(mysql)', aber diese Anforderung kann nicht bereitgestellt werden"). Ähnliche Abhängigkeitsprobleme von mariadb-11.8.5.-160000.3.1 zu mariadb-errormessages = 11.8.5 und weiteren Paketen.

Ist das ein Fehler in der Dependency-Liste des neuen Pakets?

...hatte das gleiche Problem. Es scheint wohl damit zusammen zuhängen, dass die 11.8.6 Version zwingend SSL benötigt was wiederum nicht zur Akonadi-Client-Konfiguration passt.
Wie oben beschrieben, löst ein Downgrade auf 11.8.5 das Problem.

Einen recht interessanter Artikel zu dem komplexen Hintergrund kann man hier nachlesen. Es besteht also ein viel grundsätzlicheres Problem, was auch nicht durch Wechsel der Webcam-Clients gelöst werden kann.

ich denke, hierfür wird es auf absehbare Zeit keine Lösung geben. An dem (neueren) Laptop habe ich nun die Wahl auf die Webcam-Funktion zu verzichten oder einen Distro-Wechsel in Betracht ziehen zu müssen....

Zitat von Sauerland

Wenn der Treiber der Webcam im Kernel ist, ist er nicht proprietär.

Genau. Das ist die Änderung, die jetzt kam und ermöglicht hat, dass der ipu6 Treiber in den Upstream-Kernel aufgenommen wurde (ab 6.10)

Egal, welchen Client ich nehme (v4l2, guvcview, Chrome), es wird keine Web-Camera erkannt.

Das USB UVC Protokoll wird bei diesen Kameras nicht mehr genutzt.

Gemäß dem Post hier benötige ich einen weiteren Sensor-Treiber im Kernel, eine neuere libcamera version und einen pipewire Stack, der ipu6 durchgängig unterstützt. Andere Hinweise gehen dahin, ein spezielles v4l loopback device/service einzurichten.

Sieht nach einer größeren Sache aus. Ich forsche mal weiter...

Hallo,

mein neuester Rechner (Dell Latitude 7440) hat eine Intel IPU Kamera mit proprietärer Technologie verbaut.

Da diese Technologie erst ab 6.10 im Kernel unterstützt wird, habe ich gewartet bis Tumbleweed diesen Kernel nutzt (Aktuell habe ich 6.11.0-1)

Jetzt werden auch erstmalig (seit 6.10) die Treiber intel_ipu6 und intel_ipu6_isys geladen.

Das Ganze funktioniert jetzt aber trotz dem 6.11er Kernel noch nicht "out of the box". Skype oder Zoom erkennen keine Webcam.

Welche weiteren (Installations?)Schritte sind nötig, um die proprietäre Webcam für Anwendungen verfügbar zu machen?

Die folgende udev Regeln hat bei mir das Problem gelöst

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0b95", ATTR{idProduct}=="1790", ATTR{bConfigurationValue}!="1", ATTR{bConfigurationValue}="1"

Nun wird ax88179_178a wie beabsichtigt geladen:

triton:/etc/udev/rules.d # ethtool -i enp0s20f0u2u2
driver: ax88179_178a
version: 5.14.21-150500.55.52-default
firmware-version: 
expansion-rom-version: 
bus-info: 2-2.2:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no

ok. Ich hatte gehofft, das sich das Verhalten über Konfigurationsdateien beeinflussen ließe...