Debian 12.1.0 i386 bootet nicht weiter auf ITX Board mit Intel Atom N270

[Kay Martinen]

Hallo

XP nach d.c.h.c+m.i & d.c.o.u.l.m. bitte f'up2 nach Thema selbst setzen,
Danke.

Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.

Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)

Jetzt Wollte ich versuchen OpenMediaVault darauf zu installieren. Da es
das aber nur noch in 64Bit gibt habe ich ein Debian 12.1.0 i386 genommen
und wollte die OMV Repo später dazu nehmen. Doch so weit komme ich
garnicht erst.

Vom Internen CD/DVD konnte ich nicht booten. Es wird zwar angezeigt, der
hat aber offenbar kein BBS und CDROM als Erstes Bootdevice bringt es
auch nicht zum laufen. Die CF und HDD waren natürlich entfernt und eine
60 GB SSD angeschlossen (auf der ich ein aktuelles PVE 64bit liegen habe
das weg kann). Von einem USB Stick startete es dann. Menü erscheint, ich
wähle Expert Install und sehe das laden/auspacken von vmlinuz und
initrd. Dann wird der Schirm Schwarz und links oben taucht ein
blinkender Cursor auf... ENDE. NUM-Lock lässt sich nicht umschalten was
ein Zeichen für nicht-reaktion oder stilles absterben ist, aber an
welchem Punkt genau???

Übrigens, Auch nach einer Halben Stunde warten ist da keine Reaktion. Es
kann also nicht einfach nur länger gedauert haben.

Dem N270 fehlt IMHO nur vt, sse4 und 64-bit Support, er hat HT und bis
SSE3. Aber ich denke nicht das irgendwas davon beim Booten gebraucht
wird. Es sind 1 GB von maximal möglichen 2 GB installiert aber beim
booten sollte auch das keine Rolle spielen meine ich.

Hat jemand noch eine Idee was den Unterschied ausmachen könnte?

Wie gesagt, ein EISFAIR mit Kernel Serie 5 in 32-Bit startet auf dem
ohne Probleme. Das ist aber von 3.x immer wieder aktualisiert und nicht
neu installiert worden.

Das Board hat neben der CF einen P-ATA Anschluß und 2* S-ATA

Ich weiß das der Schwachbrüstig ist. Es geht mir bei dem um ein Proof of
Concept das OMV läuft und ich es so einstellen/nutzen kann wie ich es
bräuchte. Den eigentlichen Fileserver mit Dualcore und 4 GB RAM den ich
derzeit (mit EISFAIR in 64-bit) nutze will ich evtl umrüsten auf OMV.
Aber nicht jetzt und erst wenn ich es auf einem anderen laufen hätte.

Ein Grund für den möglichen Wechsel sind UID/GID Übersetzungsprobleme
zwischen Debianesken Clients und EISFAIR. Der Nutzt 2000+ als UID und
100 als GID für 'users' und ändern geht dort nicht problemfrei. Debian
nutzt da ja eher ab 1000:1000 was auf EIS auch nicht unbedingt frei ist.
Bei nfs3 sollte das synchron sein, nfs4 funktioniert bisher nicht und
via smb bekomme ich keinen Freien Platz eines shares/Disks angezeigt.

= Obiges = Einfachste Möglichkeit, wenn's ginge. ;-/

Ｂｙｅ／
／Ｋａｙ

[Marco Moock]

Post by Kay Martinen
Von einem USB Stick startete es dann. Menü erscheint, ich
wähle Expert Install und sehe das laden/auspacken von vmlinuz und
initrd. Dann wird der Schirm Schwarz und links oben taucht ein
blinkender Cursor auf... ENDE. NUM-Lock lässt sich nicht umschalten
was ein Zeichen für nicht-reaktion oder stilles absterben ist, aber
an welchem Punkt genau???

Schaue mal, ob die Bootoption quiet aktiv ist und schalte die aus.
Geht im GRUB durch drücken von e, wenn du den Eintrag gewählt hast.


Fup2:de.comp.os.unix.linux.hardware

[Bernd Mayer]

Post by Kay Martinen
Hallo
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.
Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)
Jetzt Wollte ich versuchen OpenMediaVault darauf zu installieren. Da es
das aber nur noch in 64Bit gibt habe ich ein Debian 12.1.0 i386 genommen
und wollte die OMV Repo später dazu nehmen. Doch so weit komme ich
garnicht erst.

Hallo,

die CPU ist von 2008.

Laut Intel ist das eine CPU mit einem Kern.
https://ark.intel.com/content/www/de/de/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html

Auf anderen Webseiten finde ich die Info er hätte 2-Threads.
https://www.techpowerup.com/cpu-specs/atom-n270.c1410

Gibt fli4l infos dazu aus?

Laut der Installationsanleitung von Debian-32 werden 1-Kerner
unterstützt jedoch keine CPUs auf i586-Basis.

2.1.2.1 CPU
Nearly all x86-based (IA-32) processors still in use in personal
computers are supported. This also includes 32-bit
AMD and VIA (former Cyrix) processors, and processors like the Athlon XP
and Intel P4 Xeon.
However, Debian GNU/Linux bookworm will not run on 586 (Pentium) or
earlier processors."

https://en.wikipedia.org/wiki/Pentium_(original)

Laut
https://www.heise.de/news/Intel-stellt-Atom-230-und-Atom-N270-vor-211720.html

"Die Silverthorne- und Diamondville-Prozessoren sind in einer
In-Order-Architektur aufgebaut, die energetisch effizienter arbeitet als
die bei AMD- und anderen Intel-x86-Prozessoren seit Jahren übliche
Out-of-Order-Technik, aber weniger Performance liefert."

Offenbar hat diese CPU schon einige Besonderheiten.


Bernd Mayer

[Marco Moock]

Post by Bernd Mayer
Laut Intel ist das eine CPU mit einem Kern.
https://ark.intel.com/content/www/de/de/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html
Auf anderen Webseiten finde ich die Info er hätte 2-Threads.
https://www.techpowerup.com/cpu-specs/atom-n270.c1410

Wegen Hyper-Threading.

Post by Bernd Mayer
Laut der Installationsanleitung von Debian-32 werden 1-Kerner
unterstützt jedoch keine CPUs auf i586-Basis.

Es braucht min. die Befehlssätze des i686 (Pentium Pro). Der Atom N270
erfüllt das.

Ich vermute eher ein anderes Problem.

[Bernd Mayer]

Post by Marco Moock

Post by Bernd Mayer
Laut Intel ist das eine CPU mit einem Kern.
https://ark.intel.com/content/www/de/de/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html
Auf anderen Webseiten finde ich die Info er hätte 2-Threads.
https://www.techpowerup.com/cpu-specs/atom-n270.c1410

Wegen Hyper-Threading.

Post by Bernd Mayer
Laut der Installationsanleitung von Debian-32 werden 1-Kerner
unterstützt jedoch keine CPUs auf i586-Basis.

Es braucht min. die Befehlssätze des i686 (Pentium Pro). Der Atom N270
erfüllt das.
Ich vermute eher ein anderes Problem.

Hallo,

normalerweise werden in den Daten von Intel die Anzahl der Threads bei
Hyper-Threading aufgezählt, 2008 gab es ja schon mehr als 2.

Das Hyperthreading dieser CPU ist schon etwas ungewöhnlich.

Im Netz habe ich mittlerweile Infos gefunden, daß Notebooks mit Atom
N270 wohl mit Debian 11 laufen würden.


Bernd Mayer

[Marco Moock]

Post by Bernd Mayer

Post by Marco Moock

Post by Bernd Mayer
Laut Intel ist das eine CPU mit einem Kern.
https://ark.intel.com/content/www/de/de/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html
Auf anderen Webseiten finde ich die Info er hätte 2-Threads.
https://www.techpowerup.com/cpu-specs/atom-n270.c1410

Wegen Hyper-Threading.

Post by Bernd Mayer
Laut der Installationsanleitung von Debian-32 werden 1-Kerner
unterstützt jedoch keine CPUs auf i586-Basis.

Es braucht min. die Befehlssätze des i686 (Pentium Pro). Der Atom
N270 erfüllt das.
Ich vermute eher ein anderes Problem.

normalerweise werden in den Daten von Intel die Anzahl der Threads
bei Hyper-Threading aufgezählt, 2008 gab es ja schon mehr als 2.

Auf der Website gibt es nur eine Angabe zur Anzahl der Kerne, das ist
einer. Es gibt dann wegen HT 2 Threads.

Post by Bernd Mayer
Das Hyperthreading dieser CPU ist schon etwas ungewöhnlich.

Inwiefern?

Post by Bernd Mayer
Im Netz habe ich mittlerweile Infos gefunden, daß Notebooks mit Atom
N270 wohl mit Debian 11 laufen würden.

Die liefen auch mit Ubuntu, die CPU funktioniert ganz normal.

[Gerald E¡scher]

Post by Marco Moock

Post by Bernd Mayer
Im Netz habe ich mittlerweile Infos gefunden, daß Notebooks mit Atom
N270 wohl mit Debian 11 laufen würden.

Die liefen auch mit Ubuntu, die CPU funktioniert ganz normal.

Irgendeine Besonderheit haben die Atom. Apple hat in den XNU-Kernel von
Mac OS X vor Jahren Unterstützung für Atom eingebaut und später wieder
entfernt. Ein oder zwei Versionen von Mac OS X liefen dadurch auf
manchen Netbooks.

In der .config vom HWE-Kernel 6.2.0 von Ubuntu 22.04 finde ich
| # CONFIG_MATOM is not set
Muss wohl gesetzt sein, dass ein Kernel auf Atom läuft.

[Kay Martinen]

Post by Gerald E¡scher

Post by Marco Moock

Post by Bernd Mayer
Im Netz habe ich mittlerweile Infos gefunden, daß Notebooks mit Atom
N270 wohl mit Debian 11 laufen würden.

Und im anderen Zweig dieses Thread fand ich heute einen link unter dem
man sinngemäß bei bullseye bleiben sollte wenn...

Ich habe noch einen Acer Aspire One mit einem Minimalen Lubuntu (IMO)
der mit openhab3 läuft. Hat m.W. auch eine Atom N270

Post by Gerald E¡scher

Post by Marco Moock
Die liefen auch mit Ubuntu, die CPU funktioniert ganz normal.

Irgendeine Besonderheit haben die Atom. Apple hat in den XNU-Kernel von

32-bit i686 single-core mit Hyperthreading und in-Order Execution
vielleicht? Und wie in o.g. steht: Sie kennen die NOPL-Instruktion
nicht, das CPU-Flag dazu fehlt.

Aber sie sind nicht vulnerabel für Spectre und Meltdown. ;-)
[lscpu siehe meinen Post im nebenzweig]


Ｂｙｅ／
／Ｋａｙ

[Gerald E¡scher]

Post by Kay Martinen

Post by Gerald E¡scher
Irgendeine Besonderheit haben die Atom. Apple hat in den XNU-Kernel von

32-bit i686 single-core mit Hyperthreading und in-Order Execution
vielleicht?

Viellicht ignorierst du mein
| # CONFIG_MATOM is not set
nicht einfach, sondern versuchst herauszufinden, was es in der
Kernel-Konfiguration bewirkt?

[Kay Martinen]

Post by Gerald E¡scher

Post by Kay Martinen

Post by Gerald E¡scher
Irgendeine Besonderheit haben die Atom. Apple hat in den XNU-Kernel von

32-bit i686 single-core mit Hyperthreading und in-Order Execution
vielleicht?

Viellicht ignorierst du mein
| # CONFIG_MATOM is not set
nicht einfach, sondern versuchst herauszufinden, was es in der
Kernel-Konfiguration bewirkt?

Da bin ich nur bis zu einem punit_atom_debug vorgedrungen. Und ich hab
da nicht nach irgendwelchen Apple-spezialitäten gesucht.

Aber, ist das wirklich wichtig? Ich meine, vom fehlenden NOPL Abgesehen
scheint mir der größte unterschied das der Atom eben keine Speculative
Execution hat sondern alles In-Order ausführt. Und das eben auf den 2
möglichen (Hyper)Threads im Kern. Da kann's doch m.E. nur um
Optimierungen gehen aber ausführbar sollte dennoch jeder code sein
(außer er enthielte NOPL-Befehle) denn das ist IMO komplett transparent.

Muß es ja, denn als es diese optimierungen in Programmen noch nicht gab
mußte die CPU allein entscheiden ob sie; wenn sie's konnte; einen
thread, prozess oder programm auf einem zweiten HT-Core, einem von
mehreren echten cores parallel ausführen kann oder eben nicht. Und eben
auch ob sie vorgeladenes verwerfen muß weil der ausgeführte code dann
doch falsch ab bog oder ob sie das spekulativ ausgeführte verwenden
kann/darf.

Der Atom hat dies nicht, der führt alles sequenziell aus in der Folge
wie's kommt und er spekuliert auch nix - so weit ich weiß.

Kurz: Ob diese Option gesetzt oder nicht gesetzt ist müsste Scheißegal
sein und sich bestenfalls auf das ausführungstempo auswirken.

Siehe anderen Post von Marco. Optimierung, weiter nix.

Ｂｙｅ／
／Ｋａｙ

[Marco Moock]

Post by Gerald E¡scher
In der .config vom HWE-Kernel 6.2.0 von Ubuntu 22.04 finde ich
| # CONFIG_MATOM is not set
Muss wohl gesetzt sein, dass ein Kernel auf Atom läuft.

https://cateee.net/lkddb/web-lkddb/MATOM.html
Sieht für mich nach einer Optimierung aus.
Wer also selbst für einen Atom kompiliert, kann da setzen.
Von müssen ist aber nicht die Rede.

https://lwn.net/Articles/331539/

[Bernd Mayer]

Post by Marco Moock

Post by Bernd Mayer

Post by Marco Moock

Post by Bernd Mayer
Laut Intel ist das eine CPU mit einem Kern.
https://ark.intel.com/content/www/de/de/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html
Auf anderen Webseiten finde ich die Info er hätte 2-Threads.
https://www.techpowerup.com/cpu-specs/atom-n270.c1410

Wegen Hyper-Threading.

Post by Bernd Mayer
Laut der Installationsanleitung von Debian-32 werden 1-Kerner
unterstützt jedoch keine CPUs auf i586-Basis.

Es braucht min. die Befehlssätze des i686 (Pentium Pro). Der Atom
N270 erfüllt das.
Ich vermute eher ein anderes Problem.

normalerweise werden in den Daten von Intel die Anzahl der Threads
bei Hyper-Threading aufgezählt, 2008 gab es ja schon mehr als 2.

Auf der Website gibt es nur eine Angabe zur Anzahl der Kerne, das ist
einer. Es gibt dann wegen HT 2 Threads.

Post by Bernd Mayer
Das Hyperthreading dieser CPU ist schon etwas ungewöhnlich.

Inwiefern?

Hallo,

siehe: https://en.wikipedia.org/wiki/Pentium_(original)#References

"Intel's Larrabee multicore architecture project uses a processor core
derived from a P5 core (P54C), augmented by multithreading, 64-bit
instructions, and a 16-wide vector processing unit.[15] Intel's
low-powered Bonnell microarchitecture employed in early Atom processor
cores also uses an in-order dual pipeline similar to P5.[16]"

und: https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)

"The Bonnell microarchitecture therefore represents a partial revival of
the principles used in earlier Intel designs such as P5 and the i486,
with the sole purpose of enhancing the performance per watt ratio.
However, Hyper-Threading is implemented in an easy (i.e. low-power) way
to employ the whole pipeline efficiently by avoiding the typical single
thread dependencies.[3]"


Ich verstehe das so, daß das Hyperthreading dieser Atom-CPU N270 mit dem
des Intel P5 verwandt ist.

Vielleicht täusche ich mich auch.


Bernd Mayer

[Marco Moock]

Post by Bernd Mayer
Ich verstehe das so, daß das Hyperthreading dieser Atom-CPU N270 mit
dem des Intel P5 verwandt ist.

Der Intel 586 (Pentium) hatte kein HT. Das wurde beim Pentium 4
eingeführt.

[Bernd Mayer]

Post by Marco Moock

Post by Bernd Mayer
Im Netz habe ich mittlerweile Infos gefunden, daß Notebooks mit Atom
N270 wohl mit Debian 11 laufen würden.

Die liefen auch mit Ubuntu, die CPU funktioniert ganz normal.

Hallo,

mit welchen Versionen von Ubuntu?
Funktionieren Systeme mit Atom N270 auch mit den neueren Versionen von
Ubuntu?


Bernd Mayer

[Marco Moock]

Post by Bernd Mayer
mit welchen Versionen von Ubuntu?
Funktionieren Systeme mit Atom N270 auch mit den neueren Versionen
von Ubuntu?

16.04 auf jeden Fall, 18.04 glaub auch. Mit 19.10 wurde aber i386/i686
ganz eingestellt, sodass neuere definitiv nicht mehr laufen werden.

[Kay Martinen]

Post by Marco Moock

Post by Bernd Mayer
mit welchen Versionen von Ubuntu?
Funktionieren Systeme mit Atom N270 auch mit den neueren Versionen
von Ubuntu?

16.04 auf jeden Fall, 18.04 glaub auch. Mit 19.10 wurde aber i386/i686
ganz eingestellt, sodass neuere definitiv nicht mehr laufen werden.

Ich habe hier einen Acer Aspire One

lscpu
Architektur: i686
CPU Operationsmodus: 32-bit
Byte-Reihenfolge: Little Endian
Adressgrößen: 32 bits physical, 32 bits virtual
CPU(s): 2
Liste der Online-CPU(s): 0,1
Thread(s) pro Kern: 2
Kern(e) pro Sockel: 1
Sockel: 1
Anbieterkennung: GenuineIntel
Prozessorfamilie: 6
Modell: 28
Modellname: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
Stepping: 2
CPU MHz: 797.945
Maximale Taktfrequenz der CPU: 1600,0000
Minimale Taktfrequenz der CPU: 800,0000
BogoMIPS: 3191.81
L1d Cache: 24 KiB
L1i Cache: 32 KiB
L2 Cache: 512 KiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Not affected
Vulnerability Spectre v2: Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Markierungen: fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss h
t tm pbe constant_tsc arch_perfmon
pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr
pdcm movbe lahf_lm dtherm


Linux aspire1 5.10.0-23-686 #1 SMP Debian 5.10.179-3 (2023-07-27) i686
GNU/Linux


PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"

Gleiche CPU, Kein NOPL und läuft. Mit Grafischem Desktop und OpenHab3
(=Java).

Aber, upgrade auf Bookworm kann ich mir dort dann wohl auch schenken.

"Same Problem, Miss Debian." :-)

Man könnte auch das vorinstallierte Win 7 Starter (wieder) nehmen...
Träge, aber es läuft!

Ｂｙｅ／
／Ｋａｙ

[Bernd Mayer]

Post by Marco Moock

Post by Bernd Mayer
mit welchen Versionen von Ubuntu?
Funktionieren Systeme mit Atom N270 auch mit den neueren Versionen
von Ubuntu?

16.04 auf jeden Fall, 18.04 glaub auch. Mit 19.10 wurde aber i386/i686
ganz eingestellt, sodass neuere definitiv nicht mehr laufen werden.

Hallo,

und wie sieht es da mit Sicherheitsupdates aus?

Bernd Mayer

[Marco Moock]

Post by Bernd Mayer

Post by Marco Moock

Post by Bernd Mayer
mit welchen Versionen von Ubuntu?
Funktionieren Systeme mit Atom N270 auch mit den neueren Versionen
von Ubuntu?

16.04 auf jeden Fall, 18.04 glaub auch. Mit 19.10 wurde aber
i386/i686 ganz eingestellt, sodass neuere definitiv nicht mehr
laufen werden.

und wie sieht es da mit Sicherheitsupdates aus?

Gibt es für diese Versionen nur noch mit ESM und auch da nur für main.

[erzhausen]

Post by Kay Martinen
Hallo
XP nach d.c.h.c+m.i & d.c.o.u.l.m. bitte f'up2 nach Thema selbst setzen,
Danke.
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.
Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)

...
Hast du diesen Hinweis schon gesehen?
https://www.debian.org/releases/stable/i386/release-notes/ch-information.de.html#i386-is-i686

[Kay Martinen]

Post by erzhausen

Post by Kay Martinen
Hallo
XP nach d.c.h.c+m.i & d.c.o.u.l.m. bitte f'up2 nach Thema selbst setzen,
Danke.
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.
Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)

...
Hast du diesen Hinweis schon gesehen?
https://www.debian.org/releases/stable/i386/release-notes/ch-information.de.html#i386-is-i686

Nope! ;) Aber das könnte eine Erklärung sein wenn die NOPL Instruktion
vom bootkernel eines Debian Bookworm geprüft wird und er bei fehlen ohne
kommentar einfach stehen bliebe. Denn...

-snip-
homes # lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Address sizes: 32 bits physical, 32 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel
Model name: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
BIOS Model name: Intel(R) Atom(TM) CPU @ 1.6GHz
BIOS CPU family: 1
CPU family: 6
Model: 28
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
Stepping: 2
CPU(s) scaling MHz: 50%
CPU max MHz: 1600.0000
CPU min MHz: 800.0000
BogoMIPS: 3200.15
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
constant_tsc arch_perfmon pebs bts cpuid a
perfmperf pni dtes64 monitor ds_cpl est tm2
ssse3 xtpr pdcm movbe lahf_lm dtherm
Caches (sum of all):
L1d: 24 KiB (1 instance)
L1i: 32 KiB (1 instance)
L2: 512 KiB (1 instance)
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Not affected
Spectre v1: Not affected
Spectre v2: Not affected
Srbds: Not affected
Tsx async abort: Not affected
-snap-

Da ist kein NOPL Flag.

Allerdings erinnere ich mich das ein Installer der PAE benötigt auf
einem System das PAE nicht kann eine entsprechende Meldung ausgibt und
das reichlich früh. Warum soll das hier anders sein und der einfach
still sterben oder nichts mehr tun. Selbst einen kernel_panic könnte ich
da eher als sinnvoll ansehen, aber.... NICHTS?

Ist seltsam, oder? Immerhin scheint dies Board von den ganzen
Vulnerabilities nicht betroffen zu sein. In-Order Execution sei dank.

Ｂｙｅ／
／Ｋａｙ

[Peter J. Holzer]

Post by Kay Martinen

Post by erzhausen

Post by Kay Martinen
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.
Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)

...
Hast du diesen Hinweis schon gesehen?
https://www.debian.org/releases/stable/i386/release-notes/ch-information.de.html#i386-is-i686

Nope! ;) Aber das könnte eine Erklärung sein

Klingt plausibel.

Post by Kay Martinen
wenn die NOPL Instruktion vom bootkernel eines Debian Bookworm geprüft
wird und er bei fehlen ohne kommentar einfach stehen bliebe. Denn...

Ich halte es für viel wahrscheinlicher, dass er eben NICHT prüft, ob
diese Instruktion zur Verfügung steht, sondern sie einfach ausführt.
Wenn der Compiler Code für eine CPU generiert hat, der diese Instruktion
kennt, dann kann die an jeder Stelle im Code vorkommen. Eine Prüfung
wäre daher auch nur begrenzt sinnvoll, denn sie kann ja schon vor der
Prüfung vorkommen. Oder in dem Code der die Fehlermeldung ausgeben soll
...

Post by Kay Martinen
Allerdings erinnere ich mich das ein Installer der PAE benötigt auf
einem System das PAE nicht kann eine entsprechende Meldung ausgibt und
das reichlich früh. Warum soll das hier anders sein

Weil ein großer Unterschied besteht zwischen Instruktionen, die vom
Compiler generiert und von der CPU ausgeführt werden und Features einer
CPU, die das Betriebssystem verwenden kann oder auch nicht.

Post by Kay Martinen
und der einfach still sterben oder nichts mehr tun. Selbst einen
kernel_panic könnte ich da eher als sinnvoll ansehen, aber.... NICHTS?

Bei einer unbekannten Instruktion würde ich ein Oops erwarten, ja. Aber
eine so grundlegende Instruktion wie NOP kann natürlich auch im
Fault-Handler vorkommen. Oder die Instruktion kann auf einem älteren
Prozessor einfach etwas anderes machen.

hp

[Kay Martinen]

Post by Peter J. Holzer

Post by Kay Martinen

Post by erzhausen

Post by Kay Martinen
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.
Bisher lief der mit EISFAIR-1 32Bit und da auch so weit gut von einer 4
GB CF-Karte (mit /var und /home auf HDD)

...
Hast du diesen Hinweis schon gesehen?
https://www.debian.org/releases/stable/i386/release-notes/ch-information.de.html#i386-is-i686

wenn die NOPL Instruktion vom bootkernel eines Debian Bookworm geprüft
wird und er bei fehlen ohne kommentar einfach stehen bliebe. Denn...

Ich halte es für viel wahrscheinlicher, dass er eben NICHT prüft, ob
diese Instruktion zur Verfügung steht, sondern sie einfach ausführt.
Wenn der Compiler Code für eine CPU generiert hat, der diese Instruktion
kennt, dann kann die an jeder Stelle im Code vorkommen. Eine Prüfung
wäre daher auch nur begrenzt sinnvoll, denn sie kann ja schon vor der
Prüfung vorkommen. Oder in dem Code der die Fehlermeldung ausgeben soll

Das ist sicher richtig aber hier kann man nur vermuten. Ob z.b. die
Kernelentwickler die Prüfungen auf die verschiedensten CPU-Features und
Bugs (POPAD, PAE, ???) irgendwie hierarchisch-sequenziell sortiert durch
führen so das nicht eine Prüfung durchfällt weil das feature das sie
selbst braucht erst später geprüft wird.

Stimme dir allerdings zu das man auch durch Vorab Prüfung beim
kernelstart nicht wissen kann ob nicht später ein programm läuft das
diese Instruktion einkompiliert hat. Ich erinnere mich das die CPU
Exceptions wirft wenn sie einen illegalen Opcode findet. Kann man so was
sinnvoll abfangen und NOPL durch x*NOP ersetzen - ohne das gesamte
Timing/Programm durcheinander zu bringen? Der Handler darf dann
natürlich kein NOPL verwenden aber nach Prüfung wäre das eine
Entscheidung für eine von zwei Alternativen (Handlern). Wenn das Sinn
ergibt.

Post by Peter J. Holzer

Post by Kay Martinen
Allerdings erinnere ich mich das ein Installer der PAE benötigt auf
einem System das PAE nicht kann eine entsprechende Meldung ausgibt und
das reichlich früh. Warum soll das hier anders sein

Weil ein großer Unterschied besteht zwischen Instruktionen, die vom
Compiler generiert und von der CPU ausgeführt werden und Features einer
CPU, die das Betriebssystem verwenden kann oder auch nicht.

Stimmt. PAE betrifft in dem Fall eine Physische Erweiterung der
Adressarchitektur also einen Teil der die Funktion der ganzen CPU
beeinflußt.

Ist die Frage hier nicht eher wozu ein Long NOP gut ist, und ob er nicht
auch durch mehrere NOP in folge ersetzt werden kann - oder durch eine
Schleife die NOPs ausführt? Natürlich nicht wenn fertige binaries
ausgeführt werden, was ja erst nach dem Kernelstart mit PID 1 der fall
sein kann.

Post by Peter J. Holzer

Post by Kay Martinen
und der einfach still sterben oder nichts mehr tun. Selbst einen
kernel_panic könnte ich da eher als sinnvoll ansehen, aber.... NICHTS?

Bei einer unbekannten Instruktion würde ich ein Oops erwarten, ja. Aber
eine so grundlegende Instruktion wie NOP kann natürlich auch im
Fault-Handler vorkommen.

NOP wird wohl jede CPU können. Allerdings ging es hier ja um ein
"langes" NOP. WasAuchImmerDasMacht.

Oder die Instruktion kann auf einem älteren

Post by Peter J. Holzer
Prozessor einfach etwas anderes machen.

Z.b. als Illegaler Opcode eine Exception auslösen, einen Oops?

Ich weiß leider nicht wo, wie und warum man einen Langen NOP unbedingt
braucht und warum der nun wichtig sein sollte.

Vermuten könnte ich in richtung verhindern von Seitenkanalangriffen die
ja Timing-spezifisch sind... auf einer In-Order Architektur die dafür
nicht anfällig ist aber auch nicht passend oder?

Ｂｙｅ／
／Ｋａｙ

[Peter J. Holzer]

Post by Kay Martinen

Post by Peter J. Holzer

Post by Kay Martinen

Post by erzhausen

Post by Kay Martinen
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.

...
Hast du diesen Hinweis schon gesehen?
https://www.debian.org/releases/stable/i386/release-notes/ch-information.de.html#i386-is-i686

wenn die NOPL Instruktion vom bootkernel eines Debian Bookworm geprüft
wird und er bei fehlen ohne kommentar einfach stehen bliebe. Denn...

Ich halte es für viel wahrscheinlicher, dass er eben NICHT prüft, ob
diese Instruktion zur Verfügung steht, sondern sie einfach ausführt.
Wenn der Compiler Code für eine CPU generiert hat, der diese Instruktion
kennt, dann kann die an jeder Stelle im Code vorkommen. Eine Prüfung
wäre daher auch nur begrenzt sinnvoll, denn sie kann ja schon vor der
Prüfung vorkommen. Oder in dem Code der die Fehlermeldung ausgeben soll

Das ist sicher richtig aber hier kann man nur vermuten. Ob z.b. die
Kernelentwickler die Prüfungen auf die verschiedensten CPU-Features und
Bugs (POPAD, PAE, ???) irgendwie hierarchisch-sequenziell sortiert durch
führen so das nicht eine Prüfung durchfällt weil das feature das sie
selbst braucht erst später geprüft wird.
Stimme dir allerdings zu das man auch durch Vorab Prüfung beim
kernelstart nicht wissen kann ob nicht später ein programm läuft das
diese Instruktion einkompiliert hat. Ich erinnere mich das die CPU
Exceptions wirft wenn sie einen illegalen Opcode findet. Kann man so was
sinnvoll abfangen und NOPL durch x*NOP ersetzen

Könnte man, aber warum sollte man? Man kann ja den Kernel einfach für
das entsprechende CPU-Modell kompilieren. Da muss man keine speziellen
Tests oder Fault-Handler oder sonstwas programmieren, die das zur
Laufzeit fixen.

Dass Debian das nicht mehr macht, liegt wahrscheinlich daran, dass sie
die Zahl der Systeme, die noch eine so alte CPU haben, für
vernachlässigbar gering halten und es daher für sinnvoller halten, für
eine etwas neuere (aber immer noch sehr alte) Architektur zu
kompilieren.

Post by Kay Martinen
Ist die Frage hier nicht eher wozu ein Long NOP gut ist,

Es ist eine Instruktion, die mehrere Bytes lang ist und nichts macht.

Post by Kay Martinen
und ob er nicht auch durch mehrere NOP in folge ersetzt werden kann

Natürlich. Aber das sind dann halt mehrere Instruktionen. Macht also
länger nichts.

NOPs produziert der Compiler üblicherweise vor Sprungzielen, damit das
Sprungziel auf einer runden Adresse liegt. Z.B.:

int sum(int n) {
int s = 0;
for (int i = 1; i <= n; i++) {
s += i;
}
return s;
}


gcc -c -O2 -march=native foo.c
objdump -d foo.o

Disassembly of section .text:

0000000000000000 <sum>:
0: 85 ff test %edi,%edi
2: 7e 1c jle 20 <sum+0x20>
4: ff c7 inc %edi
6: b8 01 00 00 00 mov $0x1,%eax
b: 31 d2 xor %edx,%edx
d: 0f 1f 00 nopl (%rax)
10: 01 c2 add %eax,%edx
12: ff c0 inc %eax
14: 39 f8 cmp %edi,%eax
16: 75 f8 jne 10 <sum+0x10>
18: 89 d0 mov %edx,%eax
1a: c3 ret
1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
20: 31 d2 xor %edx,%edx
22: 89 d0 mov %edx,%eax
24: c3 ret


Bei Adresse d (unmittelbar vor der Schleife ist hier ein NOPL mit 3
Bytes Länge. Damit wird der Anfang der Schleife auf Adresse 10
verschobeb. Die ist durch 16 teilbar, was die Abarbeitung der Schleife
schneller macht. Das einzelne NOPL davor dauert maximal 1 Takt (eher
0, weil es sich mit dem XOR vorher überlappt), drei NOPs mit je 1 Byte
könnten bis zu 3 Takte brauchen. Also produziert der Compiler lieber
eine Instruktion als drei.

Post by Kay Martinen
- oder durch eine Schleife die NOPs ausführt?

Nein, das ist nicht der Zweck von NOPs. Die sollen nicht Zeit
verbrauchen, sondern Platz.

Post by Kay Martinen
Natürlich nicht wenn fertige binaries ausgeführt werden, was ja erst
nach dem Kernelstart mit PID 1 der fall sein kann.

Häh? Auch der Kernel ist ein fertiges Binary.

Post by Kay Martinen

Post by Peter J. Holzer

Post by Kay Martinen
und der einfach still sterben oder nichts mehr tun. Selbst einen
kernel_panic könnte ich da eher als sinnvoll ansehen, aber.... NICHTS?

Bei einer unbekannten Instruktion würde ich ein Oops erwarten, ja. Aber
eine so grundlegende Instruktion wie NOP kann natürlich auch im
Fault-Handler vorkommen.

NOP wird wohl jede CPU können. Allerdings ging es hier ja um ein
"langes" NOP. WasAuchImmerDasMacht.

Genau das gleiche, aber es braucht mehr Platz.

Post by Kay Martinen

Post by Peter J. Holzer
Oder die Instruktion kann auf einem älteren Prozessor einfach etwas
anderes machen.

Z.b. als Illegaler Opcode eine Exception auslösen,

Nein, das war das vor dem "oder". Ich meinte, dass sie eben kein
illegaler Opcode ist und daher keine Exception auslöst, sondern
irgendwas undokumentiertes macht. Und in der nächsten
Prozessorgeneration hat Intel dann den "unbenützten" Opcode für ein NOP
verwendet (oder eher für eine neue sinnvolle Instruktion, die mit mit
bestimmten Parametern nichts macht. Ein "normales" NOP ist ja auch
einfach ein XCHG AX, AX oder etwas in der Art).
Ist zugeben bei einem Prozessor Baujahr 2008 nicht sehr wahrscheinlich.

Post by Kay Martinen
Ich weiß leider nicht wo, wie und warum man einen Langen NOP unbedingt
braucht und warum der nun wichtig sein sollte.

Das NOPL an sich ist nicht wichtig. Es ist halt eine von diversen
Optimierungen die dem Compiler zur Verfügung stehen, wenn er für i686
Code erzeugt statt für i586. Wahrscheinlich ist es auch nicht die
einzige Instruktion, über die ein für i686 compilierter Kernel auf einem
i586 stolpern würde, aber NOPs in diversen Längen kommen halt in
compilergeneriertem Code so oft vor, dass das das erste ist, wo er sich
aufhängt. Im Allgemeinen kann Code, der für einen neueren Prozessor
einer Familie compiliert ist, auf älteren nicht ausgeführt werden.

hp

[Marco Moock]

Post by Kay Martinen
Ich weiß leider nicht wo, wie und warum man einen Langen NOP
unbedingt braucht und warum der nun wichtig sein sollte.

Der Befehlssatz steht auf den meisten aktuell genutzten CPUs zur
Verfügung und wird daher genutzt. Es kümmert kaum einen Entwickler,
wenn ein lahmer x86-Atom von vor 15 Jahren nicht genutzt werden kann.

Ist so wie bei SSE2, SSE3, x86_64: Es ist in der Breite da, hat
Vorteile und wird genutzt.

[Marco Moock]

Post by Kay Martinen
Nope! ;) Aber das könnte eine Erklärung sein wenn die NOPL
Instruktion vom bootkernel eines Debian Bookworm geprüft wird und er
bei fehlen ohne kommentar einfach stehen bliebe.

Im laufenden System wird dann eine Meldung ausgegeben.
Ggf. passiert das beim Kernel auch, wenn man quiet als
Bootoption abstellt.

[Markus Schaaf]

Post by Kay Martinen
Hallo
XP nach d.c.h.c+m.i & d.c.o.u.l.m. bitte f'up2 nach Thema selbst setzen,
Danke.
Ich habe hier ein Embedded Board (Portwell WADE ) mit einem Intel Atom
N270 der m.W. ein 32-bit Prozessor ist.

Ich nutze für so eine Hardware Archlinux32.

MfG