Bug im SuSE Kernel oder udev? /dev/rtc0' already exists,

revealed · 28 Nov. 2007

Ohne weitere Worte heir ein paar Ausgaben:

Code:

WILD-THING:/home/disk # grep rtc /var/log/boot.msg
<4>Using IPI No-Shortcut mode
<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
<4>rtc_cmos: probe of 00:03 failed with error -16
Starting udevd udevd-event[1957]: node_symlink: device node '/dev/rtc0' already exists, link '/dev/rtc' will not overwrite it
WILD-THING:/home/disk # hwclock --debug
hwclock aus util-linux-2.13-rc2
Benutze /dev interface to clock.
Letzte Abweichungskorrektur vorgenommen bei 1195398563 Sekunden nach 1969
Letzte Kalibrierung vorgenommen bei 1195398563 Sekunden nach 1969
Hardwareuhr geht nach lokaler Zeit Zeit
Die Hardwareuhr läuft vermutlich in lokaler Zeit.
Warte auf Uhrtick...
... erhielt Uhrtick
Zeit gelesen aus Hardwareuhr: 2007/11/28 22:57:42
Zeit der Hardwareuhr: 2007/11/28 22:57:42 = 1196287062 Sekunden seit 1969
Mi 28 Nov 2007 22:57:42 CET  -0.000744 Sekunden
WILD-THING:/home/disk # uname -rio
2.6.22.12-0.1-default i386 GNU/Linux
WILD-THING:/home/disk # cat /etc/SuSE-release
openSUSE 10.3 (i586)
VERSION = 10.3
WILD-THING:/home/disk #

Gruß

R

revealed · 27 Jan. 2008

Hallo! Ich bitte nochmals um Hilfe?

Ich hab im Novell Bugzilla noch keinen vergleichbaren Eintrag gefunden:
https://bugzilla.redhat.com/show_bug.cgi?id=290731

Vielleicht finde ich ihn aber auch einfach nicht...?

Wenn ich richtig verstehe liegt das irgendwie an einer Änderung mit einem oder mehreren neuen Modulen für rtc, die irgendwie gleichzeitig geladen werden?

Hier mal lsmod:

Code:

disk@wild-thing:~> lsmod | grep rtc
rtc_cmos               12064  0
rtc_core               23048  1 rtc_cmos
rtc_lib                 7040  1 rtc_core

Das hängt dann irgendwie mit udev zusammen bzw mkinitrd? Also vermutlich schon eine Kernelsache oder eine sache der Tools für den Startvorgang.

Da ich mit gefummel an udev schlechte erfahrungen habe, hab ich angst um meine Installation und werde nicht rumspielen an der Geschichte.

Gruß

R

haveaniceday · 13 Feb. 2008

Das Problem wird das fest einkompilierte "CONFIG_RTC=y" sein.
http://www.linux-club.de/viewtopic.php?p=545195#545195

Code:

Es hilft wenn du die Kernelconfig auf "# CONFIG_RTC is not set" setzt und
den Kernel neu übersetzt.
Dann kann der "andere" Treiber rtc_cmos darauf zugreifen.

Haveaniceday

revealed · 13 Feb. 2008

Danke dir für das Posting!

Aber mir ist das zu riskant. Die lösung sollte von der anderen Seite kommen und nicht vom User getätigt werden müssen.

Sicher ein Workaround aber für mich zu riskant und zeitaufwändig. Seit ich jedesmal sensors patchen musste hab ich eigentlich kein bock auf das Prozedere...

Dateien platzieren editieren konfigurieren bla... dann Kernelbasteln
neustarten lalala... dann wieder Module bauen, bootloader konfiguration festmachen. Wieder neustarten Grafikkarte nachchecken und dann hoffen...

is mir bissl zu viel Arbeit.

Gruß

R

jengelh · 14 Feb. 2008

Kanst ja ein -ccj-Kernel nehmen. Dort passiert das generell nicht.

revealed · 14 Feb. 2008

Danke dir,

aber ich versuche beim default-kernel bleiben zu können. Nimms mir nich bös, aber ich will mir nicht mehr Arbeit machen.

Aber ich hab schon öfter mal gesehen, dass der bei gewissen kritischen sachen richtig vorteilhaft scheint.

Gruß

R :roll:

gropiuskalle · 14 Feb. 2008

Nimms mir nich bös, aber ich will mir nicht mehr Arbeit machen.

Warum Arbeit? Die Kernel von jengelh laufen ganz hervorragend (zumindest für die realtime-Varianten kann ich das sagen), zudem kannst Du auch mehrere Kernel parallel laufen lassen, wenn Du lieber einen fallback-Kernel in der Hinterhand hast.

revealed · 14 Feb. 2008

naja aber es klappt doch bei mir mit dem normalen Kernel. Ich seh keinen Grund.

wollt ihr mich grad irgendwie überzeugen oder darf ich den SuSE Kernel weiter verwenden und auf Lösung des Problems spekulieren?

Wenn ich einen Grund hätte den von euch genannten Kernel zu verwenden, dann würde ich das höchst wahrscheinlich tun.

Aber ich möchte nicht noch mehr basteleien einbinden, die mich eventuell von üblichen basteleien abhalten oder einen höheren Zeitaufwand bedeuten. Und sei es dass ich Zeit verwenden muss diesen Kernel zu verstehen. Davon hab ich eh keinen Peil und ich schwimm deswegen mal einfach mit der großen Suppe mit und benutze den Kernel vom Buildservice.

Gruß

R