SMP-Kernel Problem SuSE

[Photon]

So, gibt ja auch hier den einen oder anderen Linux-Spezialisten

Ich habe vor ein paar Tagen OpenSuSE installiert. Die Installation verlief einwandfrei, doch nach dem ersten Neustart blieb der Bildschirm schwarz. Ein paar Stunden später war der "Fehler" gefunden: YAST hat den neuesten *smp* Kernel geladen. Also über CD gebootet, Kernel ausgetauscht zu *default* ( und jetzt läuft SuSE zwar, doch ohne smp-Unterstützung.

Gestern nach dem Online-Update habe ich dem neuen Kernel wieder eine Chance gegeben und siehe da: Das gleiche Problem bei der smp-Version. Derzeit läuft der 2.6.16.21-0.21-default.

Knoppix macht das gleiche. DVD rein, Bootscreen und danach nix mehr. Es scheint also festzustehen, dass sich mein System nicht mit einem SMP-Kernel verträgt. Nun frage ich mich jedoch ganz aufgeregt: Warum nicht?

SYSTEM:
ASUS M2N32-SLI DeLuxe Wireless Edition (nVidia Chipsatz)
AMD X2 64 4600+ EE
2x SATA 2
2GB RAM 800MHz

dmesg:
[...]
Nvidia board detected. Ignoring ACPI timer override.
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:11 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:11 APIC version 16
WARNING: NR_CPUS limit of 1 reached. Processor ignored.
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 7ff00000:70100000)
Checking aperture...
CPU 0: aperture @ 20c000000 size 32 MB
Aperture from northbridge cpu 0 too small (32 MB)
No AGP bridge found
Built 1 zonelists
Kernel command line: root=/dev/sda1 vga=0x31a splash=silent
bootsplash: silent mode.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2410.993 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2057384k/2096064k available (1725k kernel code, 37716k reserved, 770k data, 164k init)
Calibrating delay using timer specific routine.. 4828.92 BogoMIPS (lpj=9657849)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ stepping 02
checking if image is initramfs... it is
Freeing initrd memory: 2521k freed
not found!
Using local APIC timer interrupts.
result 12557271
Detected 12.557 MHz APIC timer.
testing NMI watchdog ... OK.
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
PCI: BIOS Bug: MCFG area is not E820-reserved
PCI: Not using MMCONFIG.
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:02:00.0
[...]

Verwende ich den SMP-Kernel steigt er einige Sekunden nach der Initialisierung aus mit der Meldung, 2 Kernelmodule nicht laden zu können (thermal/fan und noch eins) und macht einen Fallback zu /bin/sh.

Ich hoffe, jemand kann mir helfen, würde nur zu gerne SuSE rennen sehen mit 2 Kerneln Smile

Gruß,
Photon

 

[Photon]

Mehr oder weniger erledigt, Mail an bugzilla abgesetzt

 

[buggle]

Was hälst du davon, wenn du einfach die Module mal raus lässt ... weil brauchen tust du die nicht unbedingt - oder aber du installierst die, die zu deinem Kernel passen SMP Kernel brauchen "andere" Module als der normale Kernel und dann klappt das Laden logischerweise nicht mehr, weil sie einfach nicht existiern. ( Pfad falsch )

 

[Photon]

Nee, die Module für den zweiten Kernel liegen ja logischerweise in einem anderen Verzeichnis. Das Laden klappt von daher schon (also wenn es klappen würde *fg).

Allerdings lädt er ja nicht mal mit Knoppix 5.0.2, weder failsafe noch sonstwas. Auch nicht unter Debian, Ubuntu und wenn ich die Alpha 4 von Suse 10.2 Installer probiere, lädt der auch nicht. Nur Suse 10.1 mit dem Default-Kernel. Sobald ich ihm den smp-Kernel anzubieten versuche, bockt der Rechner wieder.

Es ist eine definitive Inkompatibilität mit dem Board (Chipsatz oder was auch immer, vielleicht auch Probs wegen AM2-Sockel?). Da gibt es bei Kernel.org schon mehrere Bug-Meldungen.

Trotzdem danke für Deine Idee!

EDIT: Das Schwein bootet aber mit noapic. Ich dachte diese Probleme gehören endlich der Vergangenheit an? Ohje...

Gruß,
Photon

 

[No5251]

Sorry, hatte den Thread zu spät gesehen.
Das mit "noapic" hätte ich dir gleich sagen können.

Asus ist leider eine der Firmen die sich nur im
Serverbereich um Linux-Kompatibilität kümmert.

Ich hatte den Spaß vor knapp 2 Jahren mit einem
P4P800 mit DMA-Bug und die bei Asus meinten nur
lapidar: Windows lässt sich doch installieren! ...

 

[Photon]

Sorry, hatte den Thread zu spät gesehen.
Das mit "noapic" hätte ich dir gleich sagen können.

Asus ist leider eine der Firmen die sich nur im
Serverbereich um Linux-Kompatibilität kümmert.

Ich hatte den Spaß vor knapp 2 Jahren mit einem
P4P800 mit DMA-Bug und die bei Asus meinten nur
lapidar: Windows lässt sich doch installieren! ...

Tolle Wurst. Hatte beim Kauf extra drauf geachtet und von Seiten ASUS' wurde ja auch explizit darauf hingewiesen, dass Linux-Treiber dabei sind.

Schaut man auf die CD, sind exakt 2 Treiber dabei. RPM-Pakete für SATA und den Chipsatz für die Distris RH3, RH6 und SuSE9.3. Diese Treiber sind aber schon im Kernel drin. Wenigstens bietet nVidia nach wie vor einen Klasse-Support an...

Nur weil ich Dich gerade hier habe: APIC ist doch wohl so ein interner Zeitmesser, oder -geber, oder? Nun hatte ich vor Jahren schonmal so ein Problem, da wurde das System mit noapic direkt instabil (noch mit 2.4*-Kernel). Jetzt läuft allerdings alles wunderbar stabil. Wozu wird also APIC benätigt? ACPI läuft doch trotzdem (Frequenzanpassung und Temperaturmessung funktioniert jedenfalls)

Gruß,
Photon

 

[No5251]

APIC (Advanced Programmable Interrupt Controller) ist für die Verteilung
der Interrupts zuständig, somit ein Ersatz für XT-PIC, und wird häufig mit
ACPI verwechselt oder in Verbindung gebracht. Letzteres ist jedoch lediglich
für die Energieverwaltung zuständig.
Dass APIC hin und wieder zu Fehlfunktionen führt, liegt an der leider häufig
vorkommenden schlechten Implementierung.

 

[Photon]

So, also nur der Vollständigkeit halber, falls jemanden die gleichen Probleme plagen sollte. Ich hatte Linux zu unrecht unter dem schwerem Verdacht, Scheiße zu bauen *g*

Es gibt für das Board (ASUS M2N32SLI DeLuxe) seit Kurzem ein BIOS-Update, dass die Linux-Inkompatibilität behebt. Jetzt fluppt auch APIC wieder und meine Welt ist wieder heile

Gruß,
Photon