Debian-Netinstall (31r0a) hängt bei "Debootstrap"

[Jan 'RedBully' Seiffert]

Jan-Benedict Glaw schrieb:
> On Fri, 2005-08-26 13:53:03 +0200, Jan 'RedBully' Seiffert <redbully at cc.fh-luh.de> wrote:
> 
>>Stefan Ulrich Hegner schrieb:
>>
>>>versuche grad einen antiken Testrechner mit einer
>>
>>Wie antik ist antik? 486?
> 
> 
>>Es sollte das zwar eigentlich nicht sein, da du ja das i386-image hast,
>>aber wenn dein Rechner wirklich antik ist, koennte es sein, das genau
>>beim Debootstrap ne Instruktion (im Packer, im Hashalg., beim
>>interpretieren) ausgefuehrt wird, die der Proz nicht kennt (ich hab das
>>schon mal mit nem Via C3 erlebt, der ist halt kein vollwertiger Pentium...).
> 
> 
> Das Debian userland ist mittlerweile für i486 kompiliert. Wenn auf einem
> 386'er installiert wird, muß ein 386'er Kernel installiert sein, der
> einen Emulator-Patch (für die fehlenden i486-Instruktionen) beinhaltet.
> 
Sollte das ISO dann aber nicht Bla-netinst-i486 heissen? Naja

Hmmm, was ist denn vom i386 zu i486 dazu gekommen, nen haufen
"Verwaltungsinstruktionen" (Invalidate Cache, restore TSR and
descriptor), das faellt aber eigentlich nicht von alleine aus nem
Compiler, Userlandapps koennen das meiste eh nicht gebrauchen. XADD ist
auch so ein Tier, sicher nett fuer einen der nen Syncronisationsprimitiv
implementieren will, aber dass das von alleine aus dem Compiler faellt?
Ahhh, da haben wir einen:

* BSWAP - dreht die Endianess von 32Bit - ich habs zwar jetzt nicht
  hingekriegt, das mit dem Compiler auzuspucken, zur not steckt es in
  htonl(3) & ntohl(3) (libc) und den entsprechenden Kernelgegestuecken.

Nur sein Netzwerk geht....
Naja, wobei, fuer nen einfaches HTTP/Get braucht man nur htons & ntohs
fuer den Port (und zur not nicht mal das...), das waer XCHG (oh man,
nich mal das kriegt gcc-i386 hin, gcc fuer 68k schafft es das Pedant
auszuspucken...)

Steckt es wohl in irgendeinem inline Assembly (Packer, Hash-Alg.,
Interpreter, libc) was ihm vielleicht in die Suppe spuckt.

Bei i486 zu i586 ist es etwas "schlimmer":

* CPUID - abfragen der faehigkeiten der CPU -> ist aber meist in
  Multimediacode versteckt der was mit SIMD machen will
* RDTSC - Time-Stamp-counter auslesen -> auch oft irgendwo in
  Multimediacode.
* CMOVxx - conditional move -> hier wird es Tricky, auf -march=i586
  verspritz ein gcc die Befehle, der Via C3 kann den aber nicht, darum
  ist der dann in -march=C3 nicht drin, obwohl ein C3 eignetlich i586
  ist (CPUID hat er)...

Managemant Instruktionen und Neue Spezialregister + Instruktionen mal
ausgespart.

> Das sollte man an der .config, die ja dabeiliegen sollte, sehen können.
> 
Naja, es gibt ja noch genug andere Fehlerquellen, da bin ich jetzt nur
als erstes drauf gekommen.

Man sollte es dann ja daran sehen, das Debootstrap ein SIGILL bekommt
(oder ein SIGSEGV wenns mal wieder drunter und drueber geht, wobei ein
SIGSEGV auch auf kaputtes RAM hindeutet oder andere Probleme (unerkannte
IDE-Lesefehler, ach, alles moegliche) hindeutet).

> MfG, JBG
> 
Gruss
	Jan

-- 
Thus spake the master programmer:
"Though a program be but three lines long,
someday it will have to be maintained."