Hi, ich habe hier eine Linux-Kiste, die bisher nur auf 3GB RAM lief und sich anscheinend heftig gegen eine Aufrüstung wehrt. Dabei zerschießt sie in Sekundenbruchteilen beliebige angeschlossene schreibfähige Dateisysteme, angefangen mit ihrer Bootplatte. Anscheinend alles Geräte am SCSI-Treiber, auch SD-Karten (FAT), Sticks wie HDD (ext4), also sda, sdb, sdc.. Beim Booten sieht man den Kernel erst unauffällig hochlaufen bis zum Init-Prozeß, dann geht der Schlamassel los. Reihenweise "Input/output-error" beim Abarbeiten der Init-Skripte. Z.B. bei rm, cut u.a. Exen. Bleibt dann nach ca. 20 solcher Fehlermeldungen über die ersten paar Skripte mit zerhacktem FS irgendwo stehen. Ich kann also leider kein Protokoll aus der zerstörten Maschine kriegen. Sieht mir fast so aus, als ob da ein Kernelmodul nicht wirklich 64bit-tauglich wäre oder sowas aber ich hoffe ein Linuxkundiger erkennt hier irgendein Muster in der kritischen Konfiguration. Die wäre da eine x86_64 Linux Distro - z.B. antiX oder Porteus 4 oder 5 Live-CD mit Kernel 4.x - einige mit 5.x laufen stabil AMD Athlon II 64 x4 RAM >3GB - probiert 3.5GB bis 6GB - darunter alles stabil ??
Es könnte auch ein Problem mit der Memory Map sein. Vielleicht wird RAM gesehen, wo keines ist, oder RAM taucht doppelt im Adressraum auf und wird vom Linux als getrennt betrachtet. Das könnte auf einem Missverständnis zwischen BIOS/ACPI und Linux beruhen. Der physikalische Adressraum zwischen 3GB oder 3,5GB und 4GB kann nicht für RAM genutzt werden. Manche Systeme verlieren diesen Bereich, andere wiederum mappen ihn hinter die 4GB Grenze. Schon recherchiert, ob bei diesem Mainboard-Typ solche Probleme bekannt sind? Welche RAM-Typen überhaupt zulässig sind? Letzte BIOS-Version?
:
Bearbeitet durch User
Tja eben, ist es das Board, der Speicher oder die SW? Aktuelle BIOS-Version und verschiedene RAM-Kombis, alle "supported" laut Board-Manual und mehrmals mit memtest fehlerfrei durchgelaufen. Sobald man über 3GB kommt -> Peng. Habe noch ein ähnliches altes AM2+-Board, wo komischerweise alles läuft, selber RAM, selbe Distros. Aber wie gesagt, manche Distros laufen stabil mit 3.5 bis 6GB draufgesteckt. Nach stundenlangem Googeln keinen ähnlichen Fall gefunden.
batman schrieb: > Aber wie gesagt, manche Distros laufen stabil mit 3.5 bis 6GB > draufgesteckt. Verifiziert stabil oder vermeintlich stabil? Was sagt Memtest? Passen die Timings? So klingt das für mich nach einem ggf kaputten RAM oder Mainboard. Es ist aber eh dringend Zeit für ein neues System. AM2 ist dann doch weit mehr als ein Jahrzehnt alt, jeder 50€ refurbished Büro Rechner ist da mittlerweile schneller, ich würde sogar so weit gehen und sagen, dass ein Raspberry Pi 4 schneller wäre. Sprich verschwende keine Zeit mit der Fehlersuche und muster die Kiste aus. Wenn du deine Zeit in Geld unrechnest hast du jetzt schon draufgezahlt, selbst in den Schrottcontainern findest du mittlerweile schnellere Systeme für lau.
batman schrieb: > ich habe hier eine Linux-Kiste, die bisher nur auf 3GB RAM lief und sich > anscheinend heftig gegen eine Aufrüstung wehrt. Dabei zerschießt sie in > Sekundenbruchteilen beliebige angeschlossene schreibfähige Dateisysteme Die Fragen sind: 32bit oder 64bit OS? Falls 32bit: PAE aktiv? Ich würde bei der Beschreibung des Fehlerbilds zuerst mal auf 32Bit-OS + PAE tippen, wobei die Hardware nicht wirklich für PAE ausgelegt ist. Möglich ist aber auch, dass die Hardware generell nicht mehr als 3 oder 4GB RAM kann. Es gibt etliche Chipsätze, für die das generell zutrifft und noch viel mehr Boards, auf denen Chipsätze werkeln, die zwar mehr könnten, aber vom Board entsprechend kastriert werden. Also ist die wichtigste Frage: Um welches Board genau handelt es sich? Das nicht gleich im OT exakt zu benennen, zeugt von maximaler Trolligkeit.
c-hater schrieb: > Also ist die wichtigste Frage: > Um welches Board genau handelt es sich? SEHR GUTE FRAGE. Das du noch SCSI Benutzt, lässt darauf schließen das es ein älteres Board ist. Die haben oft Memory "Geblockt", entweder wegen Eigenen Hardware (altes Shared Memory für Board-eigene Grafikkarte z.b.) oder der SCSI-Controller bedient sich irgend wo. Damals legte man das in den höheren Speicherbereich UNTER !!!! 4 GB. Was auch sein kann, ist eine Win-98 Blockade. Win-98 lief nie mit GENAU 4 GB. Also hat man einfach ein paar Bytes "entfernt". Du musst also ganz klar wissen wie das Mainboard den Speicher organisiert bzw. im Griff hat. Ich hoffe mal das die Speicherbausteine GLEICH SIND, und für das Mainboard zugelassen. !! Single + Dual gleichzeitig mögen einige Boards nicht, unterschiedliche Takt-Freq. erst recht nicht.
Die Boardspecks sind hier: https://www.asrock.com/mb/NVIDIA/Alivedual-esata2/index.asp#Specification und die anderen Fragen, die ich alle schon beantwortet habe: Es geht ausschließlich um 64-bit Systeme. Mit Memtest mehrmals in verschiedenen Konfigurationen alle Streifen durchgetestet. Es sind verschiedene aber alle laut Specs "supported" und mischbar. Und nochmal hervorgehoben, daß manche Distros auf denselben kritischen Hardwarekonfigurationen (>3GB), auch wieder 64-Bit und sogar auch manche mit anderen 4.x-Kernels stabil, also ohne Auffälligkeiten im Realbetrieb mit 3.5-6GB laufen. Die hatte ich dabei auch schön vollgepackt und belastet. Zur Erinnerung: Die kritischen Distros kommen nichtmal durch die init-Sequenz. Was könnte das jetzt bedeuten?
batman schrieb: > Was könnte das jetzt bedeuten? Das nicht alle Distributionen auf deiner antiken Hardware laufen. Oliver
batman schrieb: > Und nochmal hervorgehoben, daß manche Distros auf denselben kritischen > Hardwarekonfigurationen (>3GB), auch wieder 64-Bit und sogar auch manche > mit anderen 4.x-Kernels stabil, also ohne Auffälligkeiten im Realbetrieb > mit 3.5-6GB laufen. Die hatte ich dabei auch schön vollgepackt und > belastet. > Zur Erinnerung: Die kritischen Distros kommen nichtmal durch die > init-Sequenz. > Was könnte das jetzt bedeuten? Das du deine Zeit mit nicht funktionierenden Distributionen verschwendest, obwohl du anscheinend schon funktionierende Alternativen getestet hast. Jetzt bitte bloß nicht darum diese Herangehensweise zu bewerten. Nicht nur das der Server in Brand geraten würde, man muss eine Selbstabschaltung des kompletten Internetzes befürchten! ;-)
batman schrieb: > Die Boardspecks sind hier: > https://www.asrock.com/mb/NVIDIA/Alivedual-esata2/index.asp#Specification Aha, nach 20 Postings im Thread endlich mal erste relevante Fakten... Also gleich die nächsten Fragen: 1) Hast du das verlinkte Dokument gelesen? 2) Welche Restriktionen bei der Speichernutzung hast du dabei bemerkt? 3) Was kannst du dazu schreiben, was davon eventuell reinhaut?
c-hater schrieb: > Möglich ist aber auch, dass die Hardware generell nicht mehr als 3 oder > 4GB RAM kann. Es gibt etliche Chipsätze, für die das generell zutrifft > und noch viel mehr Boards, auf denen Chipsätze werkeln, die zwar mehr > könnten, aber vom Board entsprechend kastriert werden. Mit dem Chipsatz hat das nix zu tun. c-hater schrieb: > Also gleich die nächsten Fragen: > > 1) Hast du das verlinkte Dokument gelesen? > 2) Welche Restriktionen bei der Speichernutzung hast du dabei bemerkt? > 3) Was kannst du dazu schreiben, was davon eventuell reinhaut? Liest Du eigentlich den Thread, bevor Du schreibst?
batman schrieb: > Mit Memtest mehrmals in verschiedenen Konfigurationen alle Streifen > durchgetestet. Es sind verschiedene aber alle laut Specs "supported" und > mischbar. Ein erfolgreicher "Memtest" läßt nur eine Aussage über die Funktion in dieser Testsituation in genau dieser Testumgebung zu und trifft vor allem keine Aussage über das Zusammenspiel mit anderen das System belastende Komponenten. D.h., man kann mittels Memtest zwar defektes Ram oder im Zusammenspiel mit der gegebenen Testhardware problematisches Ram aussortieren aber nur schlecht eine Aussage über die Funktion zusammen mit anderer Hardware treffen. Deswegen hält man sich möglichst an Kompatibilitätslisten des Boardherstellers.
M.M.M schrieb: > D.h., man kann mittels Memtest zwar defektes Ram oder im Zusammenspiel > mit der gegebenen Testhardware problematisches Ram aussortieren aber nur Deshalb habe ich natürlich auch genau die Hardwarekonfiguration geprüft, auf der diese Distros obige Probleme machen. Ein Speicherfehler wurde in keinem Fall gefunden.
Schlaumaier schrieb: > Was auch sein kann, ist eine Win-98 Blockade. Win-98 lief nie mit GENAU > 4 GB. Also hat man einfach ein paar Bytes "entfernt". Wieder mal so ein Schlaummaierkäse. Natürlich läuft Win98 auch mit exakt 4GB. Ich habe hier noch neKiste stehen da läuft W98, Fedora und Solaris drauf und da stecken exakt 4GB drin. Die werden sogar von allen Systemen als physischer Speicher auch angezeigt.
Schlaumaier schrieb: > Was auch sein kann, ist eine Win-98 Blockade. Win-98 lief nie mit GENAU > 4 GB. Also hat man einfach ein paar Bytes "entfernt". Wieder mal so ein Schlaummaierkäse. Natürlich läuft Win98 auch mit exakt 4GB. Ich habe hier noch neKiste stehen da läuft W98, Fedora und Solaris drauf und da stecken exakt 4GB drin. Die werden sogar von allen Systemen als physischer Speicher auch angezeigt. batman schrieb: > Deshalb habe ich natürlich auch genau die Hardwarekonfiguration geprüft, > auf der diese Distros obige Probleme machen. Ein Speicherfehler wurde in > keinem Fall gefunden. Kannst Du mal andere probeweise andere Speicherriegel einsetzen. Ist mir selbst schon passiert, das der Speichertest durchgelaufen ist aber dann das Win sporadisch und nicht nachvollziehbar abestürzt ist. Ein weiterer Nebeneffekt ist bei der Installation von Linux (Distribution kann ich mich nicht mehr erinnern) der Installer immer abgestürzt ist und zwar jedesmal an anderen Punkten im Installationsprozeß. Mit anderen Speicherriegeln waren alle Fehler sofort behoben. Hast Du evtuell verschiede Speicherriegel miteinander gemixt?
Beitrag #7071245 wurde vom Autor gelöscht.
Beitrag #7071248 wurde vom Autor gelöscht.
Zeno schrieb: > Wieder mal so ein Schlaummaierkäse. Natürlich läuft Win98 auch mit exakt > 4GB. Ich habe hier noch neKiste stehen da läuft W98, Fedora und Solaris > drauf und da stecken exakt 4GB drin. Habe ich nie abgestritten. Ab irgend ein Service-Pack hat MS die Funktion direkt integriert. Allerdings gingen damals jede Menge Tricks durch das Netz wie man bei den NEUEN Win-98 mit 4 GB das ans laufen bekommt. Angezeigt wurden dann immer ca. 3.5 GB. Also nix Käse. Ich habe mich durch alle Windows-Versionen gefressen und ich habe ein gutes EDV-Gedächtnis. Hier z.b. einer dieser "Tricks". http://www.winfaq.de/faq_html/Content/tip1000/onlinefaq.php?h=tip1164.htm Das Netz ist voll davon.
Schlaumaier schrieb: > Angezeigt wurden dann immer ca. 3.5 GB. q.e.d. Technisch ist da Ende der Fahnenstange, wenn das Betriebssystem nur mit einen physikalischen 32-Bit-Adressraum umgehen kann. Dahinter liegen I/O-Space und BIOS. Es ist allerdings ein Unterschied, ob ein Rechner mit 4GB RAM umgehen kann, oder ob das Betriebssystem das auch vollständig nutzt. Mir scheint, euer Streit hat eben damit zu tun. In DOS ohne EMM386&Co gibts auch bei 4GB RAM nur 640KB. ;-)
:
Bearbeitet durch User
batman schrieb: > Ich kann also > leider kein Protokoll aus der zerstörten Maschine kriegen. Die Hauptplatine und das Chipset müssen unter die Lupe. Dann war früher noch die Banknutzung und die Speicherbänke selber eine Frage. Das ganze ist nicht trivial, und auch nicht wirklich gut kommuniziert - weiß der Geier, warum nicht. Man muss sich aber wirklich etwas tiefer in die Materie einarbeiten: https://en.wikipedia.org/wiki/CPU_cache Vom Bios her müsste coreboot gehen - aber da kommt es auch sehr auf die Hardware selber an - und eben auf das Know How und die Leidenschaft an sich. https://de.wikipedia.org/wiki/Coreboot Außerdem nimmt man zum Testen bewährte Standarddistributionen. Ich würde mal grml small ausprobieren.
(prx) A. K. schrieb: > Es ist allerdings ein Unterschied, ob ein Rechner mit 4GB RAM umgehen > kann, oder ob das Betriebssystem das auch vollständig nutzt. Der Rechner kann es. Das OS mit mühe nach einen Service-Pack.
Schlaumaier schrieb: > Das OS mit mühe nach einen Service-Pack. Sorgfalt hinsichtlich der (16/32/64 Bit-)Prefixe (bei so Dist-Upgrades) kann man nicht erwarten.
Schlaumaier schrieb: > Ab irgend ein Service-Pack hat MS die Funktion direkt integriert. > Allerdings gingen damals jede Menge Tricks durch das Netz wie man bei > den NEUEN Win-98 mit 4 GB das ans laufen bekommt. > > Angezeigt wurden dann immer ca. 3.5 GB. A.K. hat es ja schon bereits gesagt: Es ist ein Unterschied zwischen dem physisch vorhandenen Speicher und der Menge mit der ein OS umgehen kann. Man kann in die Kiste auch 8GB stecken, wenn das Board es kann. Das OS kann aber eben nur den Speicher nutzen den es auch adressieren kann. Da war z.B. bei DOS, wie z.B. A.K. schon ausgeführt hat, 640kB Schluß. Mit entsprechenden Treibern, ich meine es war der EMM386.EXE - weis es aber nicht mehr ganz genau , es ist zu lange her - konnte man mehr Speicher ansprechen. Die Krux bei Windows98 ist wohl das es als Unterbau immer noch auf ein 16Bit'iges DOS setzt und da ist erst mal bei 64MB Schluß mehr geht halt nicht. Dennoch kommt Win98 mit 512MB zurecht. Erst wenn man mehr Speicher hat muß man MaxPhysPage in der SYSTEM.INI im Abschitt [386Enh] setzen. Damit wird der Speicher über 512MB schlichtweg ausgeblendet und ist praktisch nicht vorhanden. Bis etwa 1,5GB funktioniert das so auch ganz gut. Bei noch mehr Arbeitsspeicher kann es dennoch zu Instabilitäten kommen. Bei Win98SE gab es dann neue 32Bit Treiber, womit es dann wieder stabiler läuft, dennoch wurde der vorhandene Arbeitsspeicher ab einer bestimmten Größe nicht mehr korrekt angezeigt. Schlaumaier schrieb: > Allerdings gingen damals jede Menge Tricks durch das Netz wie man bei > den NEUEN Win-98 mit 4 GB das ans laufen bekommt. Als Tricks würdwe ich das nun nicht unbedingt bezeichnen wollen. Das war damals alles bekannt. (prx) A. K. schrieb: > Schlaumaier schrieb: >> Angezeigt wurden dann immer ca. 3.5 GB. > > q.e.d. > > Technisch ist da Ende der Fahnenstange, wenn das Betriebssystem nur mit > einen physikalischen 32-Bit-Adressraum umgehen kann. 32Bit ergeben eigentlich 2^32=4294967296Byte und das sind 4GB und ein 32Bit sollte dies adressieren können. Win98 konnte es halt nicht richtig und hat dann das angezeigt was es meint erkannt zu haben.
Es gibt acpi tabellen, die sagen, wo was ins memory gemappt ist, was für hw es gibt, usw. Auf manchen Systemen sind die kaputt. Die Hersteller fixen das dann manchmal nicht korrekt im bios, sondern patchen Windows, und dann gehen andere OSe zip... Für einig hat Linux natürlich such workarounds, es kann also sein das neuere Kernelversionen es fixen. Ist aber auch nur reine Spekulation. Versuche mal eine Live DVD oder so zu starten, und hole dort den dmesg und lade den hier hoch. Vielleicht sieht man da dann ja was.
Zeno schrieb: > 32Bit ergeben eigentlich 2^32=4294967296Byte und das sind 4GB und ein > 32Bit sollte dies adressieren können. Nochmal: Hinter den ersten 640 KB kommt im physikalischen Adressraum das I/O Loch der ISA Ära und das Real Mode BIOS. Dann geht's bei 1 MB mit RAM weiter bis bei (ca) 3,5 GB das zweite I/O Loch vom PCI folgt, dann der Rest vom BIOS bis 4 GB. Zwischen den 3,5 und 4 GB im physikalischen Adressraum kann kein fürs OS nutzbares RAM liegen. Ob das deshalb fehlende RAM hinter den 4 GB wieder auftaucht, hängt vom Mainboard ab. Dan nützt aber nur, wenn das OS das adressieren kann.
:
Bearbeitet durch User
Bei 64 Bit wäre aber eher so bei 18446744073709551615 Schluss. Bei 128 Bit: 40282366920938463463374607431768211455 Bei 16 Bit: 2097151 Jedenfalls hatte man diese typische Anzahl von Bearbeitungsschritten für Samples beim Emu Emax2 und der war ein 16 Bit Sampler.. ( ;) )
(prx) A. K. schrieb: [...] Das grundsätzliche (historisch gewachsene) Konstrukt hast du korrekt beschrieben. Mit einer Ausnahme: > Zwischen den 3,5 und 4 GB im physikalischen Adressraum kann kein fürs > OS nutzbares RAM liegen. Das stimmt nicht. Jeder halbwegs moderne Graka-Treiber zeigt seit Dekaden das Gegenteil. Denn natürlich: es kann (und wird) hier auch RAM eingeblendet sein, nämlich der RAM der Graka (zumindest in Teilen). Und natürlich kann das OS diesen nutzen. Die Frage ist also höchstens, ob es das auch will... Tatsächlich kommt es, zumindest in Teilen, garnicht darum herum...
Eine systematische Fehlersuche könnte so aussehen: 1) Bios auf default-Werte setzen (Mainboard-Batterie ist noch ok?) 2) Falls es geht, den SCSI-Adapter entfernen und weitere Peripherie, die nicht notwendig ist. 3) Debian 32bit (i386 Paket) installieren und hier Ergebnisse berichten 4) Falls 3) erfolgreich, dann debian 64bit Paket installieren. Uns helfen auch Screenshots der Fehlermeldungen. Falls Du beim Booten dem Linux-Kernel etwas mitgeben möchtest: https://www.kernel.org/doc/html/v5.18/admin-guide/kernel-parameters.html
Japp, nahe dran. Die entscheidenden Hinweise auf eine kritische 3G-Grenze und hilfreiche Boot-Parameter fand man darin aber leider nicht, sondern man muß über dieses Stolpern:
1 | Multiple x86-64 PCI-DMA mapping implementations exist, for example: |
2 | |
3 | 1. <lib/dma-direct.c>: use no hardware/software IOMMU at all |
4 | (e.g. because you have < 3 GB memory). |
5 | Kernel boot message: "PCI-DMA: Disabling IOMMU" |
https://www.kernel.org/doc/Documentation/x86/x86_64/boot-options.txt Die Parameter "iommu=noaperture" oder "iommu=soft" beseitigen dann das Problem. Also wie vermutet, irgendein Adressenkonflikt zwischen Kernel, IOMMU- und GART-Tabellen - ohne es jetzt allzugenau wissen zu wollen, wer da was wieder wo verschlampt hat. Danke für Inspirationen und Ermutigungen! Schließlich kommen die alten Riegel vom Tisch. :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.