* Setting system clock using the hardware clock [UTC] ... * Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method.Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. * Failed to set clock You will need to set the clock yourself [ !! ] # lsmod | grep rtc_cmos # hwclock Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. # modprobe rtc_cmos # hwclock Thu 18 Dec 2008 10:32:25 AM EST -0.831872 seconds Reproducible: Always
Why should udev-124-r1 load rtc-cmos. For this to work the kernel need to either know before that rtc-cmos is needed and export this information to sysfs. As this is a platform device and no usb/pci one, udev cannot act based on vendor/device ids.
I'm sorry maybe it's a different services job to load the module? I'm pretty sure that I shouldn't have to statically compile it or add it to the statically probed modules. I assumed it was udev's job to determine the hardware on my system and load the correct modules.
[URL] still points to /etc/modules.autoload.d/kernel-2.6. If indeed nothing in the kernel specifies a module is needed after boot time, then the only way to get the module loaded is by configuring the init system to do it. So can we close this bug now? :)
do what you will, if you don't think anything should be loading it. even though it really makes /etc/conf.d/clock yell.
What kernel version do you use? Did the error occur after updating the kernel? Please also attach output of emerge --info
Created attachment 176139 [details] emerge --info currently 2.6.28-rc9 but it occurred when I was using gentoo-sources 2.6.26-r4 and 2.6.27-r7.
per earlier discussion │ CONFIG_RTC_INTF_DEV: │ │ │ │ Say yes here if you want to use your RTCs using the /dev │ │ interfaces, which "udev" sets up as /dev/rtc0 through │ │ /dev/rtcN. You may want to set up a symbolic link so one │ │ of these can be accessed as /dev/rtc, which is a name │ │ expected by "hwclock" and some other programs. │ │ │ │ This driver can also be built as a module. If so, the module │ │ will be called rtc-dev. well according to this module it seems to be udev's job to load these.
(In reply to comment #7) > per earlier discussion > > │ CONFIG_RTC_INTF_DEV: > │ > │ > │ > │ Say yes here if you want to use your RTCs using the /dev > │ > │ interfaces, which "udev" sets up as /dev/rtc0 through > │ > │ /dev/rtcN. You may want to set up a symbolic link so one > │ "Sets up" != "udev will load it" > > well according to this module it seems to be udev's job to load these. > I dont see where you read that udev will load it. Well, the conclusion of a thread on hotplug mailinglist is: The kernel exports the module alias in a different case than the rtc-cmos module. So you can try if assing something like this in a file /etc/modprobe.d/pnp-rtc-cmos: alias pnp:dPNP0B00 pnp:dPNP0b00 But this bug should be fixed in the kernel, as the kernel should export the symbols to load in the same format as the symbols its modules export. If it works we can add the alias line to the udev package.
*** Bug 252714 has been marked as a duplicate of this bug. ***
please check this Fedora Issue https://fedoraproject.org/wiki/FWN/Issue118#Cannot_Access_Hardware_Clock_Via_Any_Known_Method which is the same problem as here
Any reason you can't just modify your kernel config to build the support for rtc-cmod into the kernel instead of as a module?
I have, and that's the suggested work around, imho. the second would be static loading.
yep, that would work also. just ensure that the default kernel configuration will have rtc-cmos built in also ;-) btw there is this new option in linux-2.6.28: CONFIG_RTC_HCTOSYS: If you say yes here, the system time (wall clock) will be set using the value read from a specified RTC device. This is useful to avoid unnecessary fsck runs at boot time, and to network better. Symbol: RTC_HCTOSYS Prompt: Set system time from RTC on startup and resume Defined at drivers/rtc/Kconfig:23 Location: -> Device Drivers -> Real Time Clock (RTC_CLASS [=y])
Is there anything that can be done on udev, or is this bug just open to trace the issue further on?
unless udev can hotplug a suitable RTC driver on itself (and also /etc/init.d/clock must be started after udev), I think there is nothing else to do than building RTC_CMOS builtin into kernel and not as module
(In reply to comment #8) > Well, the conclusion of a thread on hotplug mailinglist is: The kernel exports > the module alias in a different case than the rtc-cmos module. > > So you can try if assing something like this in a file > /etc/modprobe.d/pnp-rtc-cmos: > alias pnp:dPNP0B00 pnp:dPNP0b00 > > But this bug should be fixed in the kernel, as the kernel should export the > symbols to load in the same format as the symbols its modules export. I created patch against gentoo-sources-2.6.27-r7 witch fix this. For me works fine. See attach for more info.
Created attachment 177193 [details, diff] rtc-cmos.c-fixed-alias (Uppercase B)
*** Bug 253780 has been marked as a duplicate of this bug. ***
I also encountered this bug after installing the stable gentoo-sources-2.6.27-r7 kernel. I only noticed when vmware complained about being unable to open /dev/rtc. The rtc-cmos.c-fixed-alias (Uppercase B) patch provided here fixed the problem (thank you!), and caused the rtc_cmos module to load automatically on boot. $ uname -a Linux kali 2.6.27-gentoo-r7 #1 SMP Tue Jan 6 11:29:53 CST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
More complex patch available on LKLM: http://lkml.org/lkml/2009/1/18/79
For me this thread on LKML sounds like they first need to make a decision upstream until we can do anything besides recommending to compile in rtc-cmos into the kernel.
*** Bug 260804 has been marked as a duplicate of this bug. ***
Created attachment 183735 [details, diff] PNP: fix broken pnp lowercasing for acpi module aliases Kernel developers used different approach for solving this bug: http://git.kernel.org/?p=linux/kernel/git/gregkh/driver-core-2.6.git;a=commit;h=72638f598ec9f05a43fcb22dc1dd8dc34c43acc1 Maybe this patch will work better.
