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?
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:> 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?
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. ;-)
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.
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. :)
