DivZero probiert Linux

Es gibt 231 Antworten in diesem Thema, welches 37.311 mal aufgerufen wurde. Der letzte Beitrag (5. August 2020 um 00:56) ist von c64doc.

  • Könnte aber sein.

    Wäre aber nicht Software bedingt!

    Win händelt Korrekturen anders als Linux.

    Für Elektronik oder LTspice Fragen klar bei Bitte melde dich an, um diesen Link zu sehen. nachschauen!

    Ansonsten:

    "Ich weiß nicht, mit welchen Waffen wir im 3. Weltkrieg kämpfen werden, aber im 4. werden wir uns wieder mit Keulen prügeln."

    (Albert Einstein)

  • Kannst du das bitte näher erläutern? Du meint bei solchem instabilen Hochfahren, so wie ich es heute erlebt habe, können auch Daten kaputt gehen?

  • Nein. Kaputt geht nix.

    Aber das Handling von Fehlern (welche dauernd passieren) ist bei Win und Linux verschieden.

    Was genau das ausmacht....frag mich nicht.

    Zum testen, mach noch eine weitere Dist drauf und teste.

    Sorry, mehr kann ich nicht sagen :(

    Für Elektronik oder LTspice Fragen klar bei Bitte melde dich an, um diesen Link zu sehen. nachschauen!

    Ansonsten:

    "Ich weiß nicht, mit welchen Waffen wir im 3. Weltkrieg kämpfen werden, aber im 4. werden wir uns wieder mit Keulen prügeln."

    (Albert Einstein)

  • Oft ist die GUI schuld.

    Weil das Grundsystem (Linux) immer stabil läuft.

    Für Elektronik oder LTspice Fragen klar bei Bitte melde dich an, um diesen Link zu sehen. nachschauen!

    Ansonsten:

    "Ich weiß nicht, mit welchen Waffen wir im 3. Weltkrieg kämpfen werden, aber im 4. werden wir uns wieder mit Keulen prügeln."

    (Albert Einstein)

  • Kannst du das bitte näher erläutern? Du meint bei solchem instabilen Hochfahren, so wie ich es heute erlebt habe, können auch Daten kaputt gehen?

    Wenn die Hardware OK war hatte ich bisher weder bei Linux noch bei Windows Datenverluste.

    Schau mal in die Logfiles (nicht nur die Ausgabe von 'dmesg') ob da was zu finden ist. Die meisten sind unter '/var/log' zu finden. Interessant bei Problemen mit X11, also dem Desktop sind die Logs die mit 'Xorg' anfangen. Ansonsten noch 'syslog' und 'kern.log'

  • Schwierig, wenn das System nichtmal bootet!

    Für Elektronik oder LTspice Fragen klar bei Bitte melde dich an, um diesen Link zu sehen. nachschauen!

    Ansonsten:

    "Ich weiß nicht, mit welchen Waffen wir im 3. Weltkrieg kämpfen werden, aber im 4. werden wir uns wieder mit Keulen prügeln."

    (Albert Einstein)

  • Dann könnte man immer noch mit einem Live-Stick ran. Das ist ja das schöne an Log-files. Solange man die Platte irgendwie fehlerfrei ausgelesen bekommt, braucht man keine hochkomplizierten Werkzeuge, um sich das anzusehen.

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Ich meinte, den Log zu lesen!

    Wenn nicht gebootet wird, gibts auch keinen Log

    Für Elektronik oder LTspice Fragen klar bei Bitte melde dich an, um diesen Link zu sehen. nachschauen!

    Ansonsten:

    "Ich weiß nicht, mit welchen Waffen wir im 3. Weltkrieg kämpfen werden, aber im 4. werden wir uns wieder mit Keulen prügeln."

    (Albert Einstein)

  • JA, und ich meinte, vom Live-Stick booten. Irgendwie muss das System ja auf den Rechner gekommen sein, und viele Distris bieten eine Live-Version dafür an, die dann zumeist auch läuft. Und von der aus kann man sich die Logs auf der Platte ansehen.

    [Edit:] Ich präzisiere das nochmal, was ich meine: Irgendwann lief das System ja mal. Und dass es einfach überhaupt keinen Zucker macht, glaube ich nicht. Also gibt's Logs.

    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890
    12345678901234567890123456789012345678901234567890

  • Gebootet wird ja bis zum Desktop, nur kann ich dann weder ein Programm öffnen noch in einer Konsole wechseln. Das einzige was ich jetzt beim Überfliegen gefunden habe ist solch ein Eintrag im syslog. Laut Internet sprechen einige von random hard locks mit Ryzen Vega GPUs, kann natürlich sein dass die Fehler da noch nicht ganz ausgemerzt sind.

    Aug 1 07:16:28 thelab kernel: [ 28.656106] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010

    Aug 1 07:16:28 thelab kernel: [ 28.656108] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656111] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656113] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656115] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656117] amdgpu 0000:04:00.0: RW: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656148] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)

    Aug 1 07:16:28 thelab kernel: [ 28.656151] amdgpu 0000:04:00.0: in page starting at address 0x0000000000000000 from client 18

    Aug 1 07:16:28 thelab kernel: [ 28.656154] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010

    Aug 1 07:16:28 thelab kernel: [ 28.656156] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656158] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656160] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656163] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656165] amdgpu 0000:04:00.0: RW: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656196] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)

    Aug 1 07:16:28 thelab kernel: [ 28.656199] amdgpu 0000:04:00.0: in page starting at address 0x0000000000000000 from client 18

    Aug 1 07:16:28 thelab kernel: [ 28.656201] amdgpu 0000:04:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040010

    Aug 1 07:16:28 thelab kernel: [ 28.656203] amdgpu 0000:04:00.0: MORE_FAULTS: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656206] amdgpu 0000:04:00.0: WALKER_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656208] amdgpu 0000:04:00.0: PERMISSION_FAULTS: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656210] amdgpu 0000:04:00.0: MAPPING_ERROR: 0x0

    Aug 1 07:16:28 thelab kernel: [ 28.656212] amdgpu 0000:04:00.0: RW: 0x1

    Aug 1 07:16:28 thelab kernel: [ 28.656244] amdgpu 0000:04:00.0: [mmhub0] no-retry page fault (src_id:0 ring:8 vmid:0 pasid:0, for process pid 0 thread pid 0)

  • Du könntest dir auch die aktuellsten Grafiktreiber installieren. Dazu brauchst du allerdings eine Fremdquelle.

    • sudo add-apt-repository ppa:oibaf/graphics-drivers

    einbinden, dann bist du tagesaktuell.

    Gruß Manfred (C64doc)
    Ein goldner Schraubendreher erspart unnötige Kosten

  • Heute keine Probleme mit der GUI gehabt. Man muss ja auch mal was Positives berichten, in einer Welt die von Negativschlagzeilen moniert ist und man daher schnell glauben kann, dass viel mehr Schlechtes als Gutes passiert.

  • So, ich habe ihn zum Laufen bekommen:tanz:

    In der Konfigdatei /etc/sane.d/epson2.conf habe ich das net autodiscovery durch net <meine ScannerIP> ersetzt und nun kann Sane auch mit dem Scanner arbeiten. Muss ich nur noch im DHCP Server dafür sorgen, dass der Scanner immer dieselbe IP bekommt.

    Na das was ja einfach :D

    Ist ja toll, wenn es jemand wie Du und ich ist, der nach etwas Internet Recherche sowas zum Laufen kriegen, in dem man in Config Dateien rumfummelt/frickelt.

    Aber genau DAS ist das Problem, dass es für einen DAU unzumutbar ist.

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki