Hallo zusammen,

bin ja etwas verwundert, warum sich noch keiner gemeldet hat - passiert das nur bei mir?

Habe gestern ein "pacman -Syu" durchgeführt (ohne Pakete aus testing, also ganz normal).

Das pacman Script beendet nicht sauber, nach Aktualisierung des letzten Pakets folgender Skriptfehler:
"-bash: [: -lt: Einstelliger (unärer) Operator erwartet"

Das hat zur Folge, daß nun jeder eingegebene Befehl nicht mehr ausgeführt wird, alles führt zu "illegal opcode". :-(
Das System lässt sich dann auch nicht mehr booten, der Kernel crashed.

An meiner Hardware dürfte es nicht liegen, denn ich habe daraufhin mit einem kompletten backup das System zurückgesetzt - alles bestens.
Nach erneutem Update passiert dasselbe wieder - immer beim letzten zu aktualisierenden Paket, wobei dieses nicht dasselbe sein muss.

Gruß, LW

P.S.: Passiert nur bei 32 Bit, für die 64 Bit Version ist alles ok.
Sieht mir nach einem Fehler in einem install-file aus. Ist in der pacman.log etwas zu sehen?

Und nein, ich konnte meinen i686-Laptop ohne Fehler aktualisieren.
Die Ursache dürfte nun klar sein:

Das betroffene System hat einen VIA Prozessor (daran hatte ich bislang nicht mehr gedacht).

Offenbar ist beim letzten update eine wichtige lib dabei, deren Code absolut intelspezifisch (statt generic) erzeugt wurde. Das erklärt auch den "invalid opcode" auf dem Via Prozessor.

Ich hoffe mal, das war nur ein Versehen, sonst käme archlinux für VIA Systeme wohl nicht mehr in Frage. Ist in meinem Fall zwar ne alte Mühle, verrichtet aber als kleines Mediasystem seit Jahren klaglos seine Dienste und es gab bislang auch nie Probleme.
Was für ein Via ist das genau? Manche sind nämlich nicht vollständig i686-kompatibel. Um welche lib geht es denn genau?
Pierre, es ist ein VIA nehemia, der ist ok, hatte jahrelang debian drauf und seit über einem Jahr archlinux, es gab nie Probleme :-)

Welche lib? Keine Ahnung, pacman bricht beim letzten zu installierenden Paket ab, es gibt dann generell nur noch "invalid opcode", ab dann also generell für jedes Programm, das man starten möchte.
Dann war das vorletzt vermutlich der Übeltäter. Kriegst du raus, welches das war? (pacman.conf)
Frage: Ist es gewährleistet, daß bei "pacman -Su" die zunächst gelistete Reihenfolge der upzudatenden Pakete auch der Reihenfolge NACH der Bestätigung für die Durchführung entspricht ?

Ich will den Fehler nämlich nicht so gerne nochmal provozieren, nachdem das dumme BIOS auf dem MB nur recht selten einen USB-Bootstick akzeptieren mag, das muß ich nicht unbedingt nochmal haben. ;-)
Pierre, wie gesagt, das System läuft seit Jahren klaglos.
Man kann aber doch den Compiler anweisen, "generic" code oder cpu-spezifischen Code zu erzeugen. Deswegen geht meine Vermutung in diese Richtung.

Mittlerweile habe ich nochmal einen Auszug für die upzudatenden Pakete erzeugt:
:: Starte komplette Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach Zwischen-Konflikten...

Entfernen (1): xz-utils-4.999.9beta-2  

Gesamtgröße der zu entfernenden Pakete: 0,79 MB

Pakete (20): linux-api-headers-2.6.34-1  glibc-2.12-2  zlib-1.2.5-2  
             binutils-2.20.1-3  crda-1.1.1-1  device-mapper-2.02.66-1  
             gcc-4.5.0-4  gcc-libs-4.5.0-4  openssl-1.0.0.a-2  heimdal-1.3.3-1  
             libfetch-2.31-1  libjpeg-8.0.2-1  mkinitcpio-busybox-1.16.1-4  
             mpd-0.15.10-1  smbclient-3.5.3-1  mplayer-31303-1  
             shadow-4.1.4.2-3  sudo-1.7.2p7-1  tar-1.23-3  xz-4.999.9beta-3  

Gesamtgröße der heruntergeladenen Pakete: 49,42 MB
Gesamtgröße der installierten Pakete: 222,03 MB
Nachdem der Fehler so verhängnisvoll ist, könnte "glibc" in Frage kommen.
Du kannst ja glibc downgraden und schauen, obs hilft. Falls ja, solltest Du einen Bug-Report schreiben. Die Pakete werden immer mit "generic" kompiliert.
Pierre schriebLaut http://de.wikipedia.org/wiki/VIA_C3 ist der Nehemiah kompatibel zu i686.
Der C3 ist dubios. Ich hatte auch schon einen, da hat sich das Arch-Bootmedium immer mit etwas wie "Ist kein i686" verabschiedet.
Es kommt wohl darauf an, welchen C3 man hat. Die ersten Versionen waren wohl keine i686.
Ich kann's nur wiederholen: Mein C3 läuft seit Jahren problemlos. Wichtig ist aber erstmal, daß es ein C3 "Nehemiah" ist - andere C3's sind kaum brauchbar. Der "Nehemiah" ist aber auch nur dann i686-kompatibel, wenn die Software für CPU "generic" oder "via-c3" compiliert ist.

Mittlerweile habe ich doch nochmal step-by-step installiert - "glibc" ist die Ursache.

Pierre, ein downgrade der glibc läuft natürlich. Deswegen auch meine Vermutung, daß vielleicht doch nicht für "generic" compiliert wurde - aus welchen Gründen auch immer.
Ich habe das update gerade auch auf einem eeePC (32-bit Atom) laufen lassen - keine Probleme.

Danke für Eure Mithilfe, ich werde mal einen Bug Report loslassen.

VG, LW.
17 Tage später
Etwas Zeit ist vergangen, bug report wurde durchgezogen, Fehler steht fest - vielleicht ist das Ergebnis doch, wenn auch nur vereinzelt, interessant!?

"nopl" - ein cpu code, den Intel seit Jahren in i686-Prozessoren implementiert, jedoch nie in der jeweiligen Spezifikation beschrieben hat! Schlamperei? Hmm, man ist doch eher geneigt, Absicht zu vermuten.

Die hier verwendete "Via c3 nehemiah" cpu ist nicht die einzige, die diesen Befehl nicht versteht: Der vermutlich mehr benutzte "AMD Geode" fällt genauso auf die Nase. Wie soll man auch einen kompatiblen Prozessor bauen, wenn die Specs unvollständig sind? :-(

Ein Grund mehr, warum ich lieber - soweit die Leistung annähernd vergleichbar ist - zu Konkurrenzprodukten von intel greife.

VG, LW.
LessWire schriebEtwas Zeit ist vergangen, bug report wurde durchgezogen, Fehler steht fest - vielleicht ist das Ergebnis doch, wenn auch nur vereinzelt, interessant!?
Danke für die Info. Wenn auch nicht betroffen finde ich die Sache durchaus interessant. Hat jemand ne Idee wozu man eine Long-Version von NOP braucht?

mfg, Christian
Hat jemand ne Idee wozu man eine Long-Version von NOP braucht?
Intel Instruction Set Reference schriebThe one-byte NOP instruction is an alias mnemonic for the XCHG (E)AX, (E)AX instruction.
The multi-byte NOP instruction performs no operation on supported processors and generates undefined opcode exception on processors that do not support the multibyte NOP instruction.
http://www.intel.com/Assets/pdf/manual/253667.pdf
Nopl dürfte zum Stromsparen etwas günstiger sein als NOP...
24 Tage später
Gibt es eine Lösung für das Problem? Besitze eine VIA Nehemiah CPU welche kein NOPL beherrscht. Bisher habe ich nur Kernel Patches für AMD Geode und Transmeta Crusoe gefunden.
Ich habe den Geode-Patch für den Nehemiah angepasst und verzichte aber bewusst auf ein patchfile, da mit jedem neuen Kernel wieder eine Anpassung erforderlich ist und auch nicht so viel zu ändern ist.

Es funktioniert ab Kernel 2.6.34 - notwendige Anpassungen sind:

- Kernelsources besorgen

- Datei "/arch/x86/kernel/Makefile" editieren - folgende Zeile einfügen:
...
obj-$(CONFIG_APB_TIMER)         += apb_timer.o

---- HIER FOLGENDE ZEILE EINFUEGEN ----
obj-$(CONFIG_MVIAC3_2)          += nopl_emu.o

obj-$(CONFIG_K8_NB)             += k8.o
...
- In Datei "/arch/x86/kernel/entry_32.S" die Funktion "invalid_op" folgendermassen ändern:
ENTRY(invalid_op)
        RING0_INT_FRAME
        pushl $0
        CFI_ADJUST_CFA_OFFSET 4
        pushl $do_nopl_emu
        /* pushl $do_invalid_op */
        CFI_ADJUST_CFA_OFFSET 4
        jmp error_code
        CFI_ENDPROC
END(invalid_op)
- Neue Datei mit folgendem Inhalt erzeugen und als "/arch/x86/kernel/nopl_emu.c" speichern:
/*
* linux/arch/x86/kernel/nopl_emu.c
*
* Copyright (C) 2002 Willy Tarreau
* Copyright (C) 2009 Matteo Croce
*
* Manfred Miederer did some minimal changes
* to use it for Kernel 2.6.34 and a Via Nehemiah cpu
*/

#include <linux/types.h>
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/linkage.h>
#include <asm/math_emu.h>
#include <asm/traps.h>

/* This code can be used to allow the AMD Geode / Via Nehemiah to hopefully correctly execute
* some code which was originally compiled for an i686, by emulating NOPL,
* the only missing i686 instruction in the CPU
*
* Willy Tarreau <willy@xxxxxxxxxx>
* Matteo Croce <technoboy85@xxxxxxxxx>
*/

static inline int do_1f(u8 *ip) {
    int length = 3;
    switch (*ip) {
        case 0x84:
            if (!ip[5]) length++;
            else return 0;
        case 0x80:
            if (!ip[4] && !ip[3]) length += 2;
            else return 0;
        case 0x44:
            if (!ip[2]) length++;
            else return 0;
        case 0x40:
            if (!ip[1]) length++;
            else return 0;
        case 0x00:
            return length;
    }
    return 0;
}

static inline int do_0f(u8 *ip) {
    if (*ip == 0x1f) return do_1f(ip + 1);
    return 0;
}

static inline int do_66(u8 *ip) {
 if (*ip == 0x90) return 2;
 if (*ip == 0x0f) {
    int res = do_0f(ip + 1);
    if (res) return res + 1;
    else return 0;
 }
 return 0;
}

static inline int do_start(u8 *ip) {
 if (*ip == 0x0f) return do_0f(ip + 1);
 if (*ip == 0x66) return do_66(ip + 1);
 return 0;
}

/* [do_nopl_emu] is called by exception 6 after an invalid opcode has been
 * encountered. It will try to emulate it by doing nothing,
 * and will send a SIGILL or SIGSEGV to the process if not possible.
 * the NOPL can have variable length opcodes:

bytes number opcode
 2 66 90
 3 0f 1f 00
 4 0f 1f 40 00
 5 0f 1f 44 00 00
 6 66 0f 1f 44 00 00
 7 0f 1f 80 00 00 00 00
 8 0f 1f 84 00 00 00 00 00
 9 66 0f 1f 84 00 00 00 00 00
*/
void do_nopl_emu(struct pt_regs *regs, long error_code) {
 int res = do_start((u8 *)instruction_pointer(regs));

 if (res) regs->ip += res;
 else do_invalid_op(regs, error_code);
}
Nach einigen Wochen Einsatz: es funktioniert gut!

VG, LW.

P.S.: Falls Du ein patchfile benötigst, kann ich es auf die Schnelle leider nicht erzeugen, da ich keinen archlinux Kernel auf diesem System verwende.
Vielen Dank für den Tipp.

Mal ein Patch File:
*** linux-2.6.34.orig/arch/x86/kernel/Makefile    2010-07-18 18:38:09.000000000 +0200
--- linux-2.6.34/arch/x86/kernel/Makefile    2010-07-18 18:44:54.000000000 +0200
***************
*** 89,94 ****
--- 89,96 ----
  obj-$(CONFIG_HPET_TIMER)     += hpet.o
  obj-$(CONFIG_APB_TIMER)        += apb_timer.o
  
+ obj-$(CONFIG_MVIAC3_2)          += nopl_emu.o
+ 
  obj-$(CONFIG_K8_NB)        += k8.o
  obj-$(CONFIG_DEBUG_RODATA_TEST)    += test_rodata.o
  obj-$(CONFIG_DEBUG_NX_TEST)    += test_nx.o
*** linux-2.6.34.orig/arch/x86/kernel/entry_32.S    2010-07-18 18:38:11.000000000 +0200
--- linux-2.6.34/arch/x86/kernel/entry_32.S    2010-07-18 18:46:14.000000000 +0200
***************
*** 960,966 ****
      RING0_INT_FRAME
      pushl $0
      CFI_ADJUST_CFA_OFFSET 4
!     pushl $do_invalid_op
      CFI_ADJUST_CFA_OFFSET 4
      jmp error_code
      CFI_ENDPROC
--- 960,967 ----
      RING0_INT_FRAME
      pushl $0
      CFI_ADJUST_CFA_OFFSET 4
!         pushl $do_nopl_emu
!         /* pushl $do_invalid_op */
      CFI_ADJUST_CFA_OFFSET 4
      jmp error_code
      CFI_ENDPROC