AMD64: Cannot access the Hardware Clock via any known method.

[Romendo]

During startup I get the folling messages (from hwclockfirst.sh):

 * Setting the System Clock using the Hardware Clock as reference...
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
 * System time was Thu Sep 23 16:51:05 UTC 2004.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access met[ ok ]
 * System Clock set. System local time is now Thu Sep 23 16:51:05 UTC 2004.

Running the command with the suggested --debug option:
toronto:/etc/init.d# hwclock --hctosys --utc --debug
hwclock from util-linux-2.12
hwclock: Open of /dev/rtc failed, errno=2: No such file or directory.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

My system:

AMD Athlon 64 3500+
Asus A8V Deluxe
2 GB RAM
2x Barracuda ST3120026AS 120 GB SATA hard discs
ATI Radeon 9800 Pro (128 MB)
Clean install of daily CD 20040922

[Matt Zimmerman (mdz)]

It works for me if I load the rtc module. Either the rtc module should be
autoloaded with hotplug, or it needs to be added to /etc/modules by
debian-installer.

[Tollef Fog Heen (tfheen)]

Colin, could you please make sure d-i adds rtc to the list of modules in
/etc/modules? It seems it's not possible to detect the RTC through hotplug
(it's not a PCI device), and we don't have time to implement another solution
for warty.

[Will Deutsch (wdeutsch)]

I'm using the ISO build from 9-28-04... I'm on a Tyan K8W and I'm seein the same
thing.

[torb (torrb)]

This bug is still present on the 13:th of October rc.

[Matt Zimmerman (mdz)]

The rtc module is loaded automatically somehow on i386, presumably by the
kernel. Herbert, how does this work, and is the same method applicable to x86_64?

[Chris Jones (cmsj-bugz-ubu)]

I was just having a poke around in the initrd to see if it was related to this
and I noticed something strange. When I -o loop mounted the initrd, the kernel
didn't autoload loop.ko.
It will autoload filesystems fine, but it seems to be having issues loading
things that relate to device nodes (xawtv won't cause the kernel to load bttv
and friends either, but the problem is hidden by hotplug loading modules for
everything during bootup).
I haven't figured out 2.6's module loading, or more specifically how to debug
it, yet though. I expect someone else would know though.

[Herbert Xu (herbert-gondor)]

(In reply to comment #5)
> The rtc module is loaded automatically somehow on i386, presumably by the
> kernel. Herbert, how does this work, and is the same method applicable to x86_64?

There is no difference between i386 and x86_64 in terms of the mechanisms
available to load rtc. There are three of them:

1. It's loaded when someone opens /dev/rtc.
2. It's loaded when someone loads a module which depends on it, i.e., snd-rtctimer.
3. It's loaded manually.

[Matt Zimmerman (mdz)]

Strange. So since I don't have any modules loaded which depend on it, either
something is creating /dev/rtc, or something is doing an explicit
insmod/modprobe. I don't know of any init scripts which do either of those
things, however.

[Herbert Xu (herbert-gondor)]

(In reply to comment #8)
> insmod/modprobe. I don't know of any init scripts which do either of those
> things, however.

Your dmesg should tell you when rtc was loaded. From that we may deduce what
loaded it.

[Matt Zimmerman (mdz)]

dmesg excerpt:

EXT3-fs: mounted filesystem with ordered data mode.
Adding 524276k swap on /dev/evms/swap. Priority:-1 extents:1
Real Time Clock Driver v1.12
inserting floppy driver for 2.6.8.1-3-686
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AMD 761 chipset
agpgart: Maximum main memory to use for agp memory: 1919M
agpgart: AGP aperture is 64M @ 0xe0000000
cpci_hotplug: CompactPCI Hot Plug Core version: 0.2
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:07.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
uhci_hcd 0000:00:07.2: irq 10, io base 0000c800
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1

The swap device (since it is on evms) should be activated in S35mountall.sh. I
have no idea what causes the floppy module to be loaded. The PCI device stuff
is S40hotplug. There isn't much between those two.

[Herbert Xu (herbert-gondor)]

OK I missed

4. It's loaded by hotplug through isapnp.

Unfortunately this doesn't work when isapnp isn't available.

[Matt Zimmerman (mdz)]

So for Warty, we should probably add rtc to /etc/modules on amd64. Agreed?

[Herbert Xu (herbert-gondor)]

(In reply to comment #12)
> So for Warty, we should probably add rtc to /etc/modules on amd64. Agreed?

Either that or unconditionally create the device in hotplug. Whichever is easier.

[Colin Watson (cjwatson)]

Created an attachment (id=512)
register-module rtc on amd64

[Colin Watson (cjwatson)]

Matt, OK to upload this?

Incidentally, shouldn't hwclock also be changed at some point to load rtc if it
wants to use it?

[Matt Zimmerman (mdz)]

OK to upload

[Colin Watson (cjwatson)]

ddetect (1.03ubuntu14) warty; urgency=low

  * register-module rtc on amd64 (closes: Ubuntu #1659).

 -- Colin Watson <email address hidden> Sun, 17 Oct 2004 20:13:52 +0100

[Colin Watson (cjwatson)]

This hasn't worked: hwclock.sh runs before modules are loaded from /etc/modules.

util-linux should load the modules it needs itself.

[Matt Zimmerman (mdz)]

Are you sure this hasn't worked? hwclock runs twice during the boot process,
once before modules are loaded, and one after. The second one should work.

[Jason Toffaletti (jason)]

I'm still seeing this issue in Hoary.

[reh4c (gene-hoffler)]

I am also still seeing this issue in Hoary Array 4/5. I'm just a newbie, but wanted to point this out
again to folks more knowledgable than me.

[Jamie Bennett (jamiebennett)]

(In reply to comment #19)
> Are you sure this hasn't worked? hwclock runs twice during the boot process,
> once before modules are loaded, and one after. The second one should work.

Its obviously a timing issue. Removing the first call stops the error message
and the second call works fine.

[dmatrix7 (dmatrix7)]

This bug is still present for me on Array-7. Same bug and same error that I have
got all the way back to Warty previews. Is it possible to get this annoying
cosmetic bug fixed on AMD64 before Hoary goes final?

[Matt Zimmerman (mdz)]

Yes, this annoying and trivial issue should be fixed for Hoary.

LaMont, I suggest that we do this simply, and (e.g.) suppress the error output
from the first run. How does this sound?

[Colin Watson (cjwatson)]

If we do that we'll never remember to create the device node. Wouldn't a
modprobe do the job better?

[Matt Zimmerman (mdz)]

(In reply to comment #25)
> If we do that we'll never remember to create the device node. Wouldn't a
> modprobe do the job better?

That's one option, but we do that later anyway. It's the difference between
having it work at hwclockfirst or only at hwclock

[LaMont Jones (lamont)]

What about moving the order to after module-init-tools as per Debian Bug#297543

[Giovanni Novelli (giovanni-novelli)]

During boot I get twice the following message:
"Cannot access the Hardware Clock via any know method".
A visibible impact is system clock fastly out of sync, even using an ntp server
during boot.

$uname -a
Linux ubuntu 2.6.11-1-amd64-k8-smp #1 SMP Fri Feb 11 15:42:34 UTC 2005 x86_64
GNU/Linux
# gunzip -c /proc/config.gz | grep RTC
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m

[Matt Zimmerman (mdz)]

Those are two separate issues (this message, and the clock skew)

[Giovanni Novelli (giovanni-novelli)]

Fixed the bug according to Lamont's hint (mv /etc/rcS.d/S18hwclockfirst.sh
/etc/rcS.d/S21hwclockfirst.sh) as hwclockfirst.sh was loaded before modules and
rtc comes as module with kernels 2.6.10-5-amd64-k8 and 2.6.11-1-amd64-k8-smp
that I'm relying upon.

A solution is the following:
mv /etc/rcS.d/S18hwclockfirst.sh /etc/rcS.d/S28hwclockfirst.sh

I think that this is related to /etc/rcS.d/S25libdevmapper1.00 too.
Perhaps even S26 should work.

[Giovanni Novelli (giovanni-novelli)]

I have done other experiments, trying S26, so proper fix is the following:

#mv /etc/rcS.d/S18hwclockfirst.sh /etc/rcS.d/S26hwclockfirst.sh

[Matt Zimmerman (mdz)]

Please do not change the status of this bug. The fact that you have moved the
symlinks on your system does not affect the status of the bug for anyone else.

[Giovanni Novelli (giovanni-novelli)]

(In reply to comment #29)
> Those are two separate issues (this message, and the clock skew)

Indeed, I see that fixing boot sequence for hwclockfirst.sh doesn't solve clock
skew.

[Adrian Bunk (bunk)]

Can anyone tell me the status of this issue?

As it was already explained, the time skew problem (if it is still present) is a
different issue.

I explained in Debian #297543 why S18hwclockfirst has to run before S20modutils.
As far as I understand the comments in this bug, people having problems have the
same problem later in S50hwclock.sh, too.

Is there any problem left in this bug that is neither already fixed nor related
to module loading (which isn't a problem in util-linux)?

[Matt Zimmerman (mdz)]

*** Bug 23042 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

Tollef, is this bug still relevant, is it only cosmetic, and can anything be done about it?

If only cosmetic, it can surely be downgraded, especially considering that the message will be concealed by usplash

[Matt Zimmerman (mdz)]

Tollef, please respond?

[Tollef Fog Heen (tfheen)]

I'm not exactly sure what the bug is caused by, and I can't remember seeing it for a while in dapper.

[Matt Zimmerman (mdz)]

Is anyone still seeing this in current Dapper?

[Scott James Remnant (Canonical) (canonical-scott)]

Summary:

hwclock needs the rtc module, because it needs the /dev/rtc device.

The rtc module is loaded automatically if there is an PNP0b00 device on the system, this appears to be true on both i386 and amd64 machines.

The above would have been broken for a while in dapper due to the general breakage of the kernel's PNP subsystem which has been fixed for a while.

The rtc module also appears to be explicitly seeded in /etc/modules "just in case" -- I suspect this is a bogus fix, but there may be machines which don't list the rtc in their pnp table (pre-PCI i386 and i486 perhaps)

That's loaded by /etc/rcS.d/S15module-init-tools when it iterates /etc/modules

hwclock is started in two places. The first is by a udev rule that is activated whenever the /dev/rtc device is added to the system; this is pretty failsafe no matter where the device shows up in the boot process.

The other is by /etc/rcS.d/S50hwclock.sh explicitly, which is the first point after /usr has been mounted.

So as far as I know, this should be completely fixed in dapper.

Other interesting hwclock-related bugs (while we're on the subject):
- hwclock needs /etc/localtime which is a symlink to something under /usr, which may be on a different filesystem
- dhclient fails in amusing ways if UTC=no and hwclock has not been run
- thus /usr can't be on a dhcp networked filesystem if UTC=no
- also if rtc is loaded by /etc/modules, it'll be loaded after dhclient is started, so that won't work either

[Matt Zimmerman (mdz)]

Thanks for the analysis; I think we can mark this fixed.

Subscribers: if you are still having trouble with hwclock, please reopen this bug with details.

[Raphael Kraus (raphael-raphaelkraus)]

Sorry, this bug isn't fixed for me. :( :( :(

I'm hoping this will reopen the bug?

# hwclock --hctosys --utc --debug
hwclock from util-linux-ng 2.13
hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Processor model unknown
stepping : 1
cpu MHz : 2109.566
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips : 4223.20
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Processor model unknown
stepping : 1
cpu MHz : 2109.566
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse
bogomips : 4219.14
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

[Raphael Kraus (raphael-raphaelkraus)]

This bug has appeared again for my AMD64 hardware in Gutsy (unsure of Feisty)

[Matt Zimmerman (mdz)]

On Tue, Jan 08, 2008 at 10:03:08PM -0000, Raphael Kraus wrote:
> This bug has appeared again for my AMD64 hardware in Gutsy (unsure of
> Feisty)

Has appeared again, or was never fixed?

If it was not fixed when this one was, then it's probably a different bug,
and you should file it separately rather than changing this old, resolved
report.

--
 - mdz

[Pablo Castellano (pablocastellano)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!