System hängt bei time source clock

[_dev_ich]

Moin.

Mein System hängt sich während des bootens weg.
Die letzte Meldung lautet "switching to time source clock tsc".

Danach hilft nur noch ein Kaltstart.
Die üblichen Verdächtigen, die üblichen Hinweise -nach intensiver, tagelanger Recherche-
wie acpi=off oder clocksource=hpet (Ja, High Precision Event Timer ist im BIOS aktiv)
hilft auch nix.

Klar .... wenn ich Multicoresupport im Kernel ausschalte, bootet das Gerät.
Aber ne Lösung is das nicht .

Ich hatte das Problem vor vielen Wochen schonmal und konnte es lösen....
Da mein Kernel aber durch den Neuaufbau eine ständige Baustelle war (und ist) weiß ich nicht mehr genau, welche Parameter ich da geändert habe. *sfz*

Was auffällig ist: Bevor Rechnerli ganz einfriert, schickt er noch Signale an die Tatstatur, ScrollLED und CapsLED blinken beide schnell. Dann isser ganz tot *lach*.

In welche Richtung sollte ich weiter forschen?

Aber vielleicht ist das Problem ein ganz anderes:
Wenn ich mir nämlich DMESG des funktionierenden Kernels anschaue:

[ 1.486025] Refined TSC clocksource calibration: 2295.015 MHz.
[ 1.486172] Switching to clocksource tsc
----------- Hier bleibt der defekte Kernel stehen --------------
[ 1.486439] usbcore: registered new interface driver usbhid
[ 1.486573] usbhid: USB HID core driver

Vielleicht hat Rechnerli gar kein TSC Problem, sondern erst usbcore ????

Dank!

[Max Steel]

[_dev_ich]

Einige Steine sind beiseite geräumt, ich bekomme endlich ne vernünftige Fehlermeldung, bzw überhaupt eine Fehlermeldung.

Rechnerli bemerkt, daß er unable wäre, ein rootfilesystem zu finden. Das führt dann zur großen Panik. (gif, 31kb)

Nur wurde der Bildschirm vorher so schnell gelöscht, das man nix lesen konnte.
Aber wieso wird die Root nicht gefunden??? Bei dem Kernel, der funktioniert, wird auch ein sogenanntes "806" als Root übergeben: (was immer "806" auch heißen mag :???:

[Max Steel]

[_dev_ich]

Vielleicht missverstehen wir uns? Auch im laufenden, funktionierenden Kernel hats den selben Parameter:
Dec 11 14:08:17 quadcore kernel: [ 0.000000] Command line: BOOT_IMAGE=Linux ro root=806

Also, ich weiß nicht, was "806" ist.... aber funktionieren tuts .Letztlich findet er seine root korrekterweise dann auf sda6....

Im funktionierenden Kernel wird auch HPET als Time Source benannt, da klappt das ....

[schmidicom]

[platinumviper]

root=806 bedeutet, dass das root-Filesystem auf Partition 6 der ersten SCSI/SATA Platte liegt.
Was für ein Filesystem benutzt du denn und ist es im Kernel oder wird es über eine RAM-Disk nachgeladen?
Du kannst die .config Dateien der beiden Kernel vergleichen, z.B. mit meld.
_________________
No money back garantee. In case of problems, don't call us, we call you.

[_dev_ich]

Schmidi, ja das ist der Screenshot des nicht funtionierenden Kernels, aber ich bin jetzt ein wenig weiter:
Als ich den Fehler des Screenshots
comm: swapper not tainted in der Suchmaschine
angab wurde sehr schnell deutlich, daß lediglich die SATA Unterstützung im Kernel fehlte.
Weiß der Deibel warum die fehlte, ich habe es gewiss nicht (bewusst) getan.

Muß mal prüfen ob make localmodconfig das evtl verursacht hat.

Und dann mal schauen, warum der RADEON Treiber nicht tut.
Aber jetzt ist erstmal einige Tage Gentoo-Pause, habe langes, langes WE

Was ich aber noch nie verstanden habe: Wieso kann der Kernel (/boot/mykernel) von sda6 geladen werden, aber dann die Platte nicht angesprochen werden???
Die Platte (/dev/sda) läuft doch schon, denn von ihr wurde doch der Kernel schon geladen???

Hier komme mehrere Fehler/Widrigkeiten zusammen, das werde ich am Ende mal zusammenführen.
Näheres nach dem WE

[py-ro]

Der Bootloader lädt den Kernel, der Kernel kann sich schlecht selber laden.

Der Bootloader macht dies außerdem über BIOS/EFI-Routinen und nicht über explizite Treiber.

Bye
Py

[mrsteven]

Es ist vermutlich so, wie py-ro schreibt: Der Kernel kann das root-Filesystem nicht mounten. Dafür kann es mehrere Gründe geben:

1. Der Treiber für den Festplattencontroller ist nicht fest in den Kernel kompiliert. In deinem Fall darf der Treiber kein Modul sein, weil du kein initramfs verwendest und der Kernel zum Laden des Moduls ja bereits auf die Platte zugreifen müsste. Der Bootloader, also GRUB bzw. LiLo, bringt seine eigenen Treiber mit, die eigentlich nur das BIOS/EFI ansprechen.
   
2. Der Treiber für dein root-Dateisystem fehlt im Kernel. Auch der muss fest in den Kernel kompiliert werden. Der Grund dafür ist im Wesentlichen der gleiche wie oben.
   
3. Der Kernelparameter root=xyz ist einfach falsch. Sieht in deiner lilo.conf aber okay aus, vorausgesetzt dein System liegt wirklich auf /dev/sda6.

Nur um nochmal sicher zu gehen: Du baust deinen Kernel selbst, also ohne genkernel? Dann musst du selbst dafür sorgen, dass die passenden Treiber fest in den Kernel einkompiliert werden. Mit genkernel dagegen bekommst du ein initramfs, welches die Module enthält, allerdings musst du dann auch dafür sorgen, dass das initramfs durch LiLo mitgeladen wird.

[_dev_ich]

@platinumviper
meld sieht nett aus zum .config - vergleichen, danke! Die ham da screenshots auf meld.sourceforge.net.

@Steven
nein, kein genkernel, keine init RAM. Daß SATAunterstützung kein Modul sein darf, ist klar.
Dieser Kernel hat ein march=native mit 32bit Emulation.
Eine initram will ich nur haben, wenn es unbedingt notwendig wird...
Komisch nur, daß die SATA Unterstüzung im Kernel zwischenzeitlich rausgeflogen ist.
Muß ich wohl verbockt haben.
Aber jetzt geht er wieder in runlevel2, und ich kann mich um den RADEON Kram kümmern.
Der (nicht funktionierende) Radeon Treiber scheint den Bildschirm zu löschen, sodaß man
völlig in die Irre geführt wird. Dazu dieses merkwürdige Verhalten des TSC Treibers (delay von bis zu 2 Minuten!!!) unmittelbar davor führt einen gerne mal auf die falsche Fährte

Ihr meint, daß die Festplattenunterstützung aus dem BIOS / EFI kommt.
Ich weiß nicht, ob Rechnerli EFI kennt ( eine kurze Recherche in den WIKI`s) ergab nicht viel, auch mein Lilo startet ganz konventionell. Im BIOS sehe ich nix bzgl (U)EFI.

Um den Kernel laden zu können, muss ja nicht nur das SATAdevice angesprochen werden, sondern sogar das Dateisystem (hier: ext3), da der Kernel im Dateisystem liegt. Der Kernel liegt ja auch net im MBR. Der MBR ist nix anderes als ne Tabelle, die in den ersten 512 Bytes liegt.


py-ro > Der Bootloader macht dies außerdem über BIOS/EFI-Routinen und nicht über explizite Treiber.

Schon richtig. Der Bootloader weist die Maschine an, Datei XY (hier der Linuxkernel) auf Partion <xyz> zu laden.
Das geht doch nur, wenn das Dateisystem gelesen werden kann. Die Treiber sowohl für das Gerät als auch fürs Dateisystem werden aber erst viel später geladen.
Darin liegt mein Verständnisproblem. Es ist ja nicht so, daß lilo den Kernel irgendwo anders hinkopieren würde, am Dateisystem vorbei.

Aber wir gehen damit eigentlich offtopic .

[Max Steel]

[py-ro]