Nach Bios-Update Kernel panic

[t2x]

Hi,
ich habe ein MSI 915P Neo2 Board.
Das ist auch alles wunderbar. Nur hab ich ein "kleines" Problem, und zwar folgendes.
Ich brauechte fuer ein anderes Betriebssystem das aktuelle Bios mit der Rev. 1.5.
Dieses bekomme ich aber mit Linux(Woody CD's, Knoppix, Suse usw) nicht zum laufen. Alle liefern mir diesselbe Fehlermeldung mit der ich aber leider nichts anfangen kann.



Hat vielleicht jmd von euch eine Idee woran das liegen koennte oder wie ich das wieder zum laufen bekomme? Ich hab eigentlich reichlich wenig Lust vor dem booten immer eine Biosversion fuer Windows und beim naechsten booten eine fuer Linux zu installieren.

Vielleicht koennt ihr mir ja helfen.
Vielen Dank
t2x

[gms]

hast du schon einmal "APIC=no ACPI=no" als kernel options versucht ?

[edit]
wenn du bis jetzt ein älteres Bios benutzt hasts, wahr APIC wahrscheinlich bis jetzt disabled. Das kannst du in alten Logs überprüfen.
[/edit]

[t2x]

hast du schon einmal "APIC=no ACPI=no" als kernel options versucht ?

Hat leider auch nichts gebracht.

[steos]

Kann auch nur raten: Hast du einen D-Link NIC? Ich würde einmal (auch wenn's lästig ist) alle Karten bis auf die beim Booten notwendigen aus dem Rechner entfernen und schauen, ob's dann klappt. Wenn ja, alle weiteren Karten einstecken und prüfen, bei welcher es kracht. S' sieht mir nach einem PCI Prob aus, bei dem irgendwas nicht erkannt wird. Vor Jahren hatte ich mal Probs, daß ich bei einem Rechner ausprobieren mußte, an welchen Steckplatz einzelne Karten keinen Konflikt untereinander auslösten. War ne' nette Abendbeschäftigung...

Sonst fällt mir ad hoc leider auch nichts mehr dazu ein

[gms]

Eine "vielversprechende" Kerneloption würde ich noch zusätzlich ausprobieren:
Wenn du dir den "Call Trace" anschaust, siehst du, daß die "NULL pointer dereference" in der Funktion "pcibios_sort" auftritt.
Die Kerneloption "pci=nosort" könnte diesen Funktionsaufruf völlig unterbinden.

Code: Alles auswählen

PCI: Bios reporting unknown device 00:00
unable to handle kernel NULL pointer dereference at virtual address 00000496
...
Call Trace:
pci_bios_find_device+0x1c/0x3c
pcibios_sort+0x4e/0x168
pcibios_init+0x59/0x79
do_initcalls+0x27/0xa4
init+0x88/0x1a0
init+0x0/0x1a0
kernel_thread_helper+0x5/0xc
....

Parallel würde ich überprüfen, ob dieser Fehler mit möglichst aktuellem Kernel auch reproduzierbar ist (Eventuell mit einer Kanaotix CD.) und wenn ja, dieses Problem als Kernelbug einmelden.
Das ist aber dann natürlich mit zusätzlichem Aufwand verbunden: Fehler exakt dokumentieren, eventuell Testpatches selber kompilieren und testen.

[t2x]

Eine "vielversprechende" Kerneloption würde ich noch zusätzlich ausprobieren:
Wenn du dir den "Call Trace" anschaust, siehst du, daß die "NULL pointer dereference" in der Funktion "pcibios_sort" auftritt.
Die Kerneloption "pci=nosort" könnte diesen Funktionsaufruf völlig unterbinden.

jup, das hilft. Jetzt bleibt er zwar manchmal noch bei APCI haengen aber das kenne ich schon und da hilf das APCI=off sehr gut dagegen.
Hat diese Option(pci=nosort) eigentlich irgendwelche "negativen" Auswirkungen?

Eine kleine Frage hab ich noch. Faellt irgendjemand eine Kernelkonfiguration ein, die ein ide0=....
behindert? Ich hab hier zwei Kernel beide 2.6.9 aber einer unter gentoo und einer unter debian. Unter gentoo findet er die Platten mit der ide0 Angabe unter debian bekommt er einen irq-timeout. Kann das an einem vergessenen/falschen Modul liegen?

Vielen Dank
t2x

[gms]

Hat diese Option(pci=nosort) eigentlich irgendwelche "negativen" Auswirkungen?

Nach der kargen Beschreibung die ich zu dieser Option gefunden habe, sollte sie keine groben negativen Auswirkungen haben.

zitat http://howtos.linux.com/howtos/BootPrompt-HOWTO-4.shtml

Code: Alles auswählen

Using this argument instructs the kernel to not sort the PCI devices during the probing phase.

Bootet er jetzt ohne der Sortiererei schneller

Ich hab hier zwei Kernel beide 2.6.9 aber einer unter gentoo und einer unter debian. Unter gentoo findet er die Platten mit der ide0 Angabe unter debian bekommt er einen irq-timeout. Kann das an einem vergessenen/falschen Modul liegen?

Du könntest einmale die config Dateine beider Kernel mit diff vergleichen, oder du baust dir einen Debian Kernel mit der Config von Gentoo. Wenn dann immernoch ein Unterschied besteht, liegt es wahrscheinlich an unterschiedlichen Patches