Forum: PC Hard- und Software seltsamer Linux Boot Fail bei >3GB RAM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von batman (Gast)


Lesenswert?

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

??

von michael_ (Gast)


Lesenswert?

RAM-Test?

von Cfzhfddfhijj (Gast)


Lesenswert?


von (prx) A. K. (prx)


Lesenswert?

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
von batman (Gast)


Lesenswert?

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.

von Rudi mit der Luger (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von batman (Gast)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

batman schrieb:
> Was könnte das jetzt bedeuten?

Das nicht alle Distributionen auf deiner antiken Hardware laufen.

Oliver

von Norbert (Gast)


Lesenswert?

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! ;-)

von c-hater (Gast)


Lesenswert?

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?

von M.M.M (Gast)


Lesenswert?

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?

von M.M.M (Gast)


Lesenswert?

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.

von batman (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.
von Schlaumaier (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von rbx (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

(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.

von rbx (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von rbx (Gast)


Lesenswert?

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..

( ;) )

von c-hater (Gast)


Lesenswert?

(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...

von Pete K. (pete77)


Lesenswert?

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

von batman (Gast)


Lesenswert?

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.