FS#9636 - [initscripts-2008.02-1] "Cannot access the hardware clock" error message on start
Attached to Project:
Arch Linux
Opened by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 08:14 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 29 March 2008, 22:20 GMT
Opened by Frederic Bezies (fredbezies) - Thursday, 21 February 2008, 08:14 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 29 March 2008, 22:20 GMT
|
Details
Description: Since I upgraded less than an hour ago udev to
its last version, I get a "Cannot access the hardware clock
via any known method" error message.
A little google tells me it's related to udev. Can't say if it can be seen on i686. Additional info: * udev-118-2 Steps to reproduce: Just update udev and reboot your arch ;) Not a killing bug, but it seems to slow down a little (around 3% ?!) boot time. |
This task depends upon
Found this thread, showing this bug on fedora "trunk", thread 3 weeks old...
Could have some more infos ?!
fedora-devel-list@redhat.com/8500636.html"> http://www.opensubscriber.com/message/fedora-devel-list@redhat.com/8500636.html
Allow --directisa configuration for hwclock calls
Look in /etc/rc.conf for a line like this:
USEDIRECTISA="yes"
Without that one, the initscripts won't use the directisa parameter, which could fail on your system.
@Other devs: can't we make this one the default when there's no USEDIRECTISA setting in rc.conf? Some (most?) people don't merge their rc.conf after an upgrade.
I added this line in my /etc/rc.conf and it changed nothing. Same error at startup.
50 if [ "$USEDIRECTISA" != "no" ]; then
51 HWCLOCK_PARAMS="$HWCLOCK_PARAMS --directisa"
52 fi
we use hwclock to set the time before udev is started, which means /dev isn't populated yet. hwclock needs /dev/rtc, which isn't there. The simple workaround is to have a /dev/rtc in /dev before a ramdisk is mounted there.
I wonder if it can be fixed in a way like this: http://projects.archlinux.org/git/?p=initscripts.git;a=commit;h=c2d7f40b2e0837f5544e6e2bfc22dc12e994ed16
Dépôt : testing
Nom : initscripts
Version : 2008.02-1
URL : --
Licences : --
Groupes : base
Fournit : --
Dépend de : glibc bash awk grep coreutils sed udev>=118
net-tools ncurses
Dépendances opt. : --
Incompatible avec : --
Remplace : --
A télécharger : 17,28 K
Taille (installé) : 17,28 K
Paqueteur : --
Architecture : --
Compilé le : --
somme MD5 : a3ed28b214423554c6c9fa85845d8b5b
Description : System initialization/bootup scripts
Latest in testing I think ?
I think the following should fix the issue:
1) include rtc_cmos.ko in initcpio image
2) make sure it is loaded before hwclock
3) create /dev/misc/rtc0 with device numbers 254, 0
4) create /dev/rtc symlink to /dev/misc/rtc0
Note that this works with kernels >= 2.6.24 only, old kernels use just /dev/rtc with numbers 10, 135
Also, I'm not sure if support for other RTC drivers is needed.
Udev started: udev-devent[919]: node_symlink: device node '/dev/rtc' already exists, link to '/dev/rtc0'
according to the bugreport referrenced above, see my previous comment
it seems your system doesn't allow direct setting of CMOS by hwclock, so it falls back to using /dev/rtc.
Sure, it's still a bug, I'm just curious about the hardware.
EDIT: I guess this is the same kind of hardware that required us to introduce the USEDIRECTISA option.
An acer one, based on VIA K8M800 chipset. 2 and half years old (October 2005) for a Sempron 3100+ => Acer Aspire T135.
If sysinfo is right :
MOTHERBOARD
Host bridge
Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Subsystem: VIA Technologies, Inc. K8M800 Host Bridge
PCI bridge(s)
VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode])
USB controller(s)
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI])
ISA bridge
VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
Subsystem: Giga-byte Technology GA-7VT600 Motherboard
IDE interface
VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology GA-7VAX Mainboard
Perhaps adding MODULES="rtc_cmos" to the mkinitcpio image will help?
I *think* this is hardware specific, as it doesn't happen on my machine. However, it IS mostly cosmetic...
Recommended fix? Just pre-create a /dev/rtc node?
for .24 kernels - as in #3 & #4 I've said above,
for .23 kernels - as Jan said.
users with hardware problems could add rtc module to their mkinitcpio by hand (it could be also statically compiled it into kernel, but I don't like that)
@Frederic: you'll have to test the soultion by yourself, because we cannot do this on our hardware.
please try to add MODULES="rtc_cmos" to mkinitcpio.conf and rebuild the image,
if that won't help - try also adding #3 and #4 before the first hwclock call in rc.sysinit
Besides a little slow down on start and the error message, everything is ok.
Frederic, I will look into fixing this at the package level so you do not need to do anything. One of my machines had a similar error on boot, so I can verify it working or not
Edit /etc/rc.sysinit and go to line 25. Underneat the 3 mknod calls, add the following lines:
/bin/mknod /dev/misc/rtc0 c 10 135
/bin/ln -s /dev/rtc /dev/misc/rtc0
the "10 135" might need to be "0 254" - I think Roman knows better here. This shouldn't harm anything, but I can't test it for some time.
$ ll /dev/misc/rtc
crw-rw-r-- 1 root audio 10, 135 2008-02-20 18:33 /dev/misc/rtc
$ uname -r
2.6.24-ARCH
https://bugzilla.redhat.com/show_bug.cgi?id=290731#c4
Red Hat has:
# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
CONFIG_RTC_DRV_CMOS=m
We have
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_RTC_DRV_CMOS=m
As I understood from reading some more comments - CONFIG_RTC is "the old driver" (10 135),
and when it's disabled - the device is "0 254".
BTW, it seems CONFIG_RTC and CONFIG_GEN_RTC should not be enabled at the same time,
this is fixed in .25 tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=09b6bdb3b6a95fe270107c2831e033f9cb233d2d
I think our kernel config could be improved in RTC section, I'm digging more into it...
FS#9649to stop bugspamming here. :)Suggestions?
They are both running on AMD 690G based Boards with HPET activated and both have the newest testing-kernel.
edit /etc/rc.sysinit and go to line 25. Underneat the 3 mknod calls, add the following lines:
/bin/mknod /dev/misc/rtc0 c 0 254
/bin/ln -s /dev/rtc /dev/misc/rtc0
going to git soon...
tpowa did the testing on his hardware
/bin/mkdir /dev/misc/bin/: no such file or directory
/bin/mknod /dev/misc/rtc: no such file or directory
Followed by the usual error message about not being able to access hardware clock...
I also get two additional errors (which my or may be related) -- during the first udev startup step (udev 118-6):
(...) /dev/pts: file exists
(...) /dev/shm: file exists
The two latter errors (/dev/pts and /dev/shm) still show up though -- the problem seems to be that the directories mkdir command tries to create (/dev/pts and /dev/shm) are somehow created earlier and already exist... The mkdir command for these directories is apparently called twice in the latest rc.sysinit -- lines 34-35 and 82-83).
Eric, Pierre, please confirm.
I don't know where to look for the issue :(
will try to search more tomorrow (gtg sleep now).
The package seems to introduce a new problem, though -- "/sbin/minilogd" from line 38 returns "No such file or directory" error.
Pierre, it seems you're the only one left.
Could you try these variants:
1) call `modprobe rtc_cmos` (and try to load other rtc_* too) before hwclock in rc.sysinit
2) see what device number /dev/misc/rtc0 has after boot, and if there is /dev/misc/rtc1, and also if `lsmod | grep rtc` after boot shows something other than rtc_core and rtc_cmos.
/bin/mknod /dev/misc/rtc0 c 252 0
to
/bin/mknod /dev/misc/rtc0 c 253 0
Eric. could you check if 253 breaks hwclock again on your system?