# 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  :Wink: .

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 wrote:*   

> 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*.
> 
> Dank!

 

Das ist das Zeichen für einen Kernelpanic. Üblicherweiße sollte es durchgehend blinken.

----------

## _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 :???:  :Shocked: 

```

Dec 11 14:08:17 quadcore kernel: [    0.000000] Kernel command line: BOOT_IMAGE=Linux ro root=806
```

DEVTMPFS ist via Kernel verfügbar:

```

quaDCore ~ # grep -i devtmpfs /usr/src/linux/.config

CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

quaDCore ~ #
```

Der ganze Kram scheint also mit der der Time Source Clock nur bedingt was zu tun zu haben.

Doch durch das Löschen von Stout, ist der TSC-Kram lediglich der letzte funktionierende Prozess den man noch sehen kann aber nicht unbedingt die Ursache.  :Wink: 

Ich habe den RADEON Treiber aus dem Kernel rausgenommen, -bzw als Modul kompilieren lassen- seitdem wird endlich der Blidschirm nicht mehr gelöscht, jetzt sieht man zumindest den Fehler.... Da ich das leider nicht abspeichern konnte, musste ich den Bug fotografieren!!! Wie steinzeitlich *lach*! Deswegen das Bild/der Fehler da oben eingefügt.

Ein Problem mit dem RADEON Treiber gibt es offensichtlich auch noch, aber sehe ich keinen Zusammenhang, oder kenne ihn nicht   :Rolling Eyes:  .

An der lilo.conf liegt es nicht, es werden beiden Kerneln die selben Parameter übergeben:

Paste der lilo.conf:

Vielleicht kommt ja dem einen oder dem anderen die eine oder die andere Idee???

Danke!Last edited by _dev_ich on Tue Dec 11, 2012 10:22 pm; edited 1 time in total

----------

## Max Steel

 *_dev_ich wrote:*   

> 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.
> ...

 

Wo kommt denn die  806 her? Das hört sich an als hätte jemand in der bootloader-config ein paar Zeichen gelöscht und aus root=/dev/sda1 vga=0x806 eben root=806 gemacht ^^

SChau das mal nach und überarbeite es entsprechend ^^ (das vga= gedöns brauchste btw nich unbedingt... war nur ein Gedankengang)

----------

## _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   :Rolling Eyes:  .Letztlich findet er seine root korrekterweise dann auf sda6....

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

```

Dec 11 23:42:09 quadcore kernel: [    0.000000] hpet clockevent registered

```

----------

## schmidicom

 *_dev_ich wrote:*   

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

 

Dein "Screenshot" sagt da aber was anderes "Cannot open root device ...".

----------

## 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.

----------

## _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  :Wink: 

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  :Wink: 

----------

## py-ro

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

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:

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.

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.

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   :Confused: 

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  :Smile: .

----------

## Max Steel

 *_dev_ich wrote:*   

> 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.
> ...

 

Der Bootloader weißt das BIOS an ihm von der Festplatte die Daten runterzusaugen und nutzt dafür die Dateisystemtreiber vom Bootloader  :Wink: 

Also der Bootloader sagt dem BIOS "ich brauch die Daten und so musst du das System da drauf interpretiern, lad das mal in den RAM und starte die Stelle 0x00000001

Aber ansonsten, es funktioniert, warum sich darüber den Kopf zerbrechen  :Razz: 

----------

## py-ro

 *_dev_ich wrote:*   

> 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.
> 
> .

 

lilo machts anhand der Blocknummern, Grub hat Filesystem Treiber.

----------

