"New" Real Time Clock driver won't work on HP DL380 G4/G5

Bug #293484 reported by Tatsuya Noda
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Fedora)
Fix Released
Low
linux (Ubuntu)
Fix Released
Medium
Andy Whitcroft
Intrepid
Fix Released
Medium
Andy Whitcroft

Bug Description

same as https://bugzilla.redhat.com/show_bug.cgi?id=451188 .
tested with DL380 G4 with linux-image-2.6.27-7-server_2.6.27-7.14 and/or linux-image-2.6.27-7-generic_2.6.27-7.15.

Revision history for this message
In , shr (shr-redhat-bugs) wrote :

Description of problem:
Fedora 9 use the "new" Real Time Clock Driver (Device Drivers ---> Real Time
Clock), but it don't work on HP DL380 G4/G5.
I don't know

Version-Release number of selected component (if applicable):
All the kernel released for Fedora 9 (kernel-2.6.25-14.fc9.x86_64 ~
kernel-2.6.25.4-30.fc9.x86_64)

How reproducible:
Install Fedora9 on HP DL380 G4/G5

Steps to Reproduce:
1. Just install Fedora9 on HP DL380 G4/G5
2.
3.

Actual results:
/dev/rtc0 won't be created.

Expected results:
/dev/rtc0 will be created and a symbolic link /dev/rtc will link to /dev/rtc0

Additional info:
It will work with "old" Real Time Clock driver,
(Device Drivers ---> Character devices ---> Enhanced Real Time Clock Support
(and Generic /dev/rtc emulation) ).
If "new" Real Time Clock Driver won't work on HP DL380 G4/G5 even in the future,
could you please compile the "old" Real Time Clock driver as module?

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Are there any error messages in the log about the driver not loading/working?
Does the output of 'lsmod' show it is loaded?

Revision history for this message
In , shr (shr-redhat-bugs) wrote :

I don't know how to get the right information, could you please tell me what
information I can provide and how can I get it(what command should I execute) to
help solve this problem?
It is ok If you need all the output of dmesg and lsmod. (about 578 + 48 lines)
Following is the information I can get.

Fedora 9 On HP DL380G4 (use new rtc driver and don't work)
# ls -al /dev/rtc*
ls: cannot access /dev/rtc*: No such file or directory

# dmesg | grep -i rtc
<nothing>

#lsmod | grep -i rtc
<nothing>

# clock --systohc --debug
hwclock from util-linux-ng 2.13.1
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.

Fedora 9 On IBM BladeCenter HS21 (use new rtc driver and working)
# ls -al /dev/rtc*
lrwxrwxrwx 1 root root 4 2008-06-16 22:07 /dev/rtc -> rtc0
crw-r--r-- 1 root root 254, 0 2008-06-16 22:07 /dev/rtc0

# dmesg | grep -i rtc
ACPI: RTC can wake from S4
rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one year

#lsmod | grep -i rtc
<nothing>

Fedora 8 On HP DL380G4 (Use old char -> rtc and working)
# ls -alt /dev/rtc*
crw-r--r-- 1 root root 10, 135 2008-06-10 20:32 /dev/rtc

# dmesg | grep -i rtc
<nothing>

#lsmod | grep -i rtc
<nothing>

Revision history for this message
In , shr (shr-redhat-bugs) wrote :

The same for HP DL 360G5, does HP use strange rtc chip on it's Server?

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Please post the entire boot messages file (/var/log/dmesg) after booting the broken kernel.

Revision history for this message
In , manuel (manuel-redhat-bugs-1) wrote :
Download full text (32.9 KiB)

Although I'm not sure, I think the problem is that the HP servers are not exporting the RTC via PNP.

From ./drivers/rtc/rtc-cmos.c:
static const struct pnp_device_id rtc_ids[] = {
        { .id = "PNP0b00", },
        { .id = "PNP0b01", },
        { .id = "PNP0b02", },
        { },
};

# cat /sys/devices/pnp0/*/id
PNP0a03
PNP0c02
IPI0001
PNP0103
PNP0200
PNP0800
PNP0303
PNP0f13
PNP0f0e
PNP0a06
PNP0501
PNP0500

dmesg
storage1:~ # dmesg
Initializing cgroup subsys cpuset
Linux version 2.6.25.14-108.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Mon Aug 4 13:46:35 EDT 2008
Command line: ro root=/dev/VolGroup00/LogVol00
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000cfe56000 (usable)
 BIOS-e820: 00000000cfe56000 - 00000000cfe5e000 (ACPI data)
 BIOS-e820: 00000000cfe5e000 - 00000000cfe5f000 (usable)
 BIOS-e820: 00000000cfe5f000 - 00000000d0000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000022ffff000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 851542) 1 entries of 3200 used
Entering add_active_range(0, 851550, 851551) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293759) 3 entries of 3200 used
end_pfn_map = 2293759
DMI 2.4 present.
ACPI: RSDP 000F4F00, 0024 (r2 HP )
ACPI: XSDT CFE567C0, 0074 (r1 HP ProLiant 2 Ò 162E)
ACPI: FACP CFE56840, 00F4 (r3 HP ProLiant 2 Ò 162E)
ACPI: DSDT CFE56940, 1FB8 (r1 HP DSDT 1 INTL 20030228)
ACPI: FACS CFE56100, 0040
ACPI: SPCR CFE56140, 0050 (r1 HP SPCRRBSU 1 Ò 162E)
ACPI: MCFG CFE561C0, 003C (r1 HP ProLiant 1 0)
ACPI: HPET CFE56200, 0038 (r1 HP ProLiant 2 Ò 162E)
ACPI: SPMI CFE56240, 0040 (r5 HP ProLiant 1 Ò 162E)
ACPI: ERST CFE56280, 01D0 (r1 HP ProLiant 1 Ò 162E)
ACPI: APIC CFE56480, 009E (r1 HP ProLiant 2 0)
ACPI: FFFF CFE56540, 0176 (r1 HP ProLiant 1 Ò 162E)
ACPI: BERT CFE566C0, 0030 (r1 HP ProLiant 1 Ò 162E)
ACPI: HEST CFE56700, 00BC (r1 HP ProLiant 1 Ò 162E)
No NUMA configuration found
Faking a node at 0000000000000000-000000022ffff000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 851542) 1 entries of 3200 used
Entering add_active_range(0, 851550, 851551) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 2293759) 3 entries of 3200 used
Bootmem setup node 0 0000000000000000-000000022ffff000
  NODE_DATA [0000000000012000 - 0000000000019fff]
  bootmap [000000000001a000 - 000000000005ffff] pages 46
early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2 [200000-752...

Revision history for this message
In , shr (shr-redhat-bugs) wrote :
Download full text (24.6 KiB)

Bad news again...

In 2.6.25 kernel, I can compile the old rtc driver by myself.
In 2.6.26.5 kernel, I can't find the rtc config in Device Drivers -> Character devices anymore...

Following is the dmesg on HPDL380 G4

Initializing cgroup subsys cpuset
Linux version 2.6.26.3-29.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Wed Sep 3 03:16:37 EDT 2008
Command line: ro root=/dev/VolGroup00/LogVol00
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000dfff3000 (usable)
 BIOS-e820: 00000000dfff3000 - 00000000dfffb000 (ACPI data)
 BIOS-e820: 00000000dfffb000 - 00000000e0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000021bfff000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 25600 used
Entering add_active_range(0, 256, 917491) 1 entries of 25600 used
Entering add_active_range(0, 1048576, 2211839) 2 entries of 25600 used
max_pfn_mapped = 2211839
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
init_memory_mapping
DMI 2.3 present.
ACPI: RSDP 000F4F00, 0024 (r2 HP )
ACPI: XSDT DFFF3300, 004C (r1 HP P51 2 � 162E)
ACPI: FACP DFFF3380, 00F4 (r3 HP P51 2 � 162E)
ACPI: DSDT DFFF3480, 2DAB (r1 HP DSDT 1 INTL 20030228)
ACPI: FACS DFFF3100, 0040
ACPI: SPCR DFFF3140, 0050 (r1 HP SPCRRBSU 1 � 162E)
ACPI: MCFG DFFF31C0, 003C (r1 HP ProLiant 1 0)
ACPI: APIC DFFF3200, 00C2 (r1 HP 00000083 2 0)
ACPI: SSDT DFFF8000, 04C9 (r1 HP SSDTP 1 INTL 20030228)
No NUMA configuration found
Faking a node at 0000000000000000-000000021bfff000
Entering add_active_range(0, 0, 159) 0 entries of 25600 used
Entering add_active_range(0, 256, 917491) 1 entries of 25600 used
Entering add_active_range(0, 1048576, 2211839) 2 entries of 25600 used
Bootmem setup node 0 0000000000000000-000000021bfff000
  NODE_DATA [0000000000012000 - 0000000000026fff]
  bootmap [0000000000027000 - 000000000006a7ff] pages 44
  early res: 0 [0-fff] BIOS data page
  early res: 1 [6000-7fff] TRAMPOLINE
  early res: 2 [200000-84a54b] TEXT DATA BSS
  early res: 3 [37c90000-37fef058] RAMDISK
  early res: 4 [9f400-fffff] BIOS reserved
  early res: 5 [8000-11fff] PGTABLE
 [ffffe20000000000-ffffe20002dfffff] PMD -> [ffff810001200000-ffff810003ffffff] on node 0
 [ffffe20002e00000-ffffe200077fffff] PMD -> [ffff81000c000000-ffff8100103fffff] on node 0
Zone PFN ranges:
  DMA 0 -> 4096
  DMA32 4096 -> 1048576
  Normal 1048576 -> 2211839
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
    0: 0 -> 159
    0: 256 -> 917491
    0: 1048576 -> 2211839
On node 0 totalpages: 2080657
  DMA zone: 56 pages used for memmap
  DMA zone: 1721 pages reserved
  DMA zone: 2222 pages, LIFO batch:0...

Revision history for this message
In , shr (shr-redhat-bugs) wrote :
Download full text (28.5 KiB)

The same problem exists on HP blade server, maybe on MOST of HP servers...
HP PC like dc7800/dc7600 and NB like Compaq 6910p don't have this problem.

The following is working OLD rtc driver dmesg on HP DL380G4 with Fedora 8 installed, is it helpful?

Initializing cgroup subsys cpuset
Linux version 2.6.25.6-27.fc8 (mockbuild@x86-2) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Fri Jun 13 16:17:54 EDT 2008
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000dfff3000 (usable)
 BIOS-e820: 00000000dfff3000 - 00000000dfffb000 (ACPI data)
 BIOS-e820: 00000000dfffb000 - 00000000e0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 000000019bfff000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 917491) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 1687551) 2 entries of 3200 used
end_pfn_map = 1687551
DMI 2.3 present.
ACPI: RSDP 000F4F00, 0024 (r2 HP )
ACPI: XSDT DFFF3300, 0044 (r1 HP P51 2 Ò 162E)
ACPI: FACP DFFF3380, 00F4 (r3 HP P51 2 Ò 162E)
ACPI: DSDT DFFF3480, 2D62 (r1 HP DSDT 1 INTL 20030228)
ACPI: FACS DFFF3100, 0040
ACPI: SPCR DFFF3140, 0050 (r1 HP SPCRRBSU 1 Ò 162E)
ACPI: MCFG DFFF31C0, 003C (r1 HP ProLiant 1 0)
ACPI: APIC DFFF3200, 00C2 (r1 HP 00000083 2 0)
No NUMA configuration found
Faking a node at 0000000000000000-000000019bfff000
Entering add_active_range(0, 0, 159) 0 entries of 3200 used
Entering add_active_range(0, 256, 917491) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 1687551) 2 entries of 3200 used
Bootmem setup node 0 0000000000000000-000000019bfff000
  NODE_DATA [0000000000010000 - 0000000000017fff]
  bootmap [0000000000018000 - 000000000004b7ff] pages 34
early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2 [200000-757aeb] TEXT DATA BSS
early res: 3 [37c17000-37fefc61] RAMDISK
early res: 4 [9f400-a03ff] EBDA
early res: 5 [8000-ffff] PGTABLE
 [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001200000 on node 0
 [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
 [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001a00000 on node 0
 [ffffe20000600000-ffffe200007fffff] PMD ->ffff810001e00000 on node 0
 [ffffe20000800000-ffffe200009fffff] PMD ->ffff810002200000 on node 0
 [ffffe20000a00000-ffffe20000bfffff] PMD ->ffff810002600000 on node 0
 [ffffe20000c00000-ffffe20000dfffff] PMD ->ffff810002a00000 on node 0
 [ffffe20000e00000-ffffe20000ffffff] PMD ->ffff810002e00000 on node 0
 [ffffe20001000000-ffffe200011fffff] PMD ->ffff810003200000 on node 0
 [ffffe20001200000-ffffe200013fffff] PMD ->ffff810003600000 on node 0
 [ffffe20001400000-ffffe200015...

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Patch from the upstream bug report is reported to fix the problem.

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Fix for upstream patch:

Subject: acpi-cope-with-pnpacpi-tables-missing-an-rtc-entry-fix
From: Andrew Morton <email address hidden>

Cc: <email address hidden>
Cc: Adam Belay <email address hidden>
Cc: Alessandro Zummo <email address hidden>
Cc: Bjorn Helgaas <email address hidden>
Cc: Chuck Ebbert <email address hidden>
Cc: David Brownell <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Len Brown <email address hidden>
Cc: Rik Theys <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
---

 include/asm-x86/mc146818rtc.h | 2 ++
 1 file changed, 2 insertions(+)

diff -puN include/asm-x86/mc146818rtc.h~acpi-cope-with-pnpacpi-tables-missing-an-rtc-entry-fix include/asm-x86/mc146818rtc.h
--- a/include/asm-x86/mc146818rtc.h~acpi-cope-with-pnpacpi-tables-missing-an-rtc-entry-fix
+++ a/include/asm-x86/mc146818rtc.h
@@ -9,6 +9,8 @@
 #include <asm/processor.h>
 #include <linux/mc146818rtc.h>

+struct device;
+
 #ifndef RTC_PORT
 #define RTC_PORT(x) (0x70 + (x))
 #define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Until that fix gets into a release, you can work around the problem by booting with the kernel option "pnpacpi=off".

Revision history for this message
In , shr (shr-redhat-bugs) wrote :

Setting the kernel option "pnpacpi=off" is working fine on my systems. I am wondering if it will cause any other problem?

The newest kernel on Fedora 9 ,"kernel-2.6.26.5-45.fc9.x86_64", hasn't included the fix...

Revision history for this message
In , Bjorn (bjorn-redhat-bugs) wrote :
Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Upstream patches merged:
2.6.27.1-20.fc10
2.6.26.6-77.fc9
2.6.26.6-48.fc8

Revision history for this message
In , shr (shr-redhat-bugs) wrote :

Yes, it's working

[root@HPDL360G5-1 ~]# uname -a
Linux HPDL360G5-1.lab.icst.org.tw 2.6.27.2 #1 SMP Wed Oct 22 16:39:56 CST 2008 x86_64 x86_64 x86_64 GNU/Linu

[root@HPDL360G5-1 ~]# dmesg | grep -i rtc
platform rtc_cmos: registered platform RTC device (no PNP device found)
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, hpet irqs

[root@HPDL360G5-1 ~]# ls -al /dev/rtc*
lrwxrwxrwx 1 root root 4 2008-10-23 00:49 /dev/rtc -> rtc0
crw-r--r-- 1 root root 254, 0 2008-10-23 00:49 /dev/rtc0

kernel 2.6.27.2

rtc.c line 216-
static struct platform_device rtc_device = {
        .name = "rtc_cmos",
        .id = -1,
        .resource = rtc_resources,
        .num_resources = ARRAY_SIZE(rtc_resources),
};

static __init int add_rtc_cmos(void)
{
#ifdef CONFIG_PNP
        static const char *ids[] __initconst =
                { "PNP0b00", "PNP0b01", "PNP0b02", };
        struct pnp_dev *dev;
        struct pnp_id *id;
        int i;

        pnp_for_each_dev(dev) {
                for (id = dev->id; id; id = id->next) {
                        for (i = 0; i < ARRAY_SIZE(ids); i++) {
                                if (compare_pnp_id(id, ids[i]) != 0)
                                        return 0;
                        }
                }
        }
#endif

        platform_device_register(&rtc_device);
        dev_info(&rtc_device.dev,
                "registered platform RTC device (no PNP device found)\n");
        return 0;
}
device_initcall(add_rtc_cmos);

rtc-cmos.c line 1021-
static struct platform_driver cmos_platform_driver = {
        .remove = __exit_p(cmos_platform_remove),
        .shutdown = cmos_platform_shutdown,
        .driver = {
                .name = (char *) driver_name,
                .suspend = cmos_suspend,
                .resume = cmos_resume,
        }
};

static int __init cmos_init(void)
{
        int retval = 0;

#ifdef CONFIG_PNP
        pnp_register_driver(&cmos_pnp_driver);
#endif

        if (!cmos_rtc.dev)
                retval = platform_driver_probe(&cmos_platform_driver,
                                                cmos_platform_probe);

        if (retval == 0)
                return 0;

#ifdef CONFIG_PNP
        pnp_unregister_driver(&cmos_pnp_driver);
#endif
        return retval;
}
module_init(cmos_init);

static void __exit cmos_exit(void)
{
#ifdef CONFIG_PNP
        pnp_unregister_driver(&cmos_pnp_driver);
#endif
}
module_exit(cmos_exit);

MODULE_AUTHOR("David Brownell");
MODULE_DESCRIPTION("Driver for PC-style 'CMOS' RTCs");
MODULE_LICENSE("GPL");

Changed in linux:
status: Unknown → Fix Released
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Tatsuya,

Thanks for the note. It looks like one of the patches has already been applied to the Intrepid kernel:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=0020f5cf510e3225fc4b0eefdcfdc0caba2f2097

But the other one looks looks to be missing:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=72f22b1eb6ca5e4676a632a04d40d46cb61d4562

I'll reassign to the kernel team and open an Intrepid nomination. Thanks.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
milestone: none → intrepid-updates
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
Andy Whitcroft (apw) wrote :

The second patch nominated above has already hit the Intrepid tree, releasing with Ubuntu-2.6.27-10.20 which has already hit all of the intrepid pockets:

  commit 4afe6284da5e161ce0c069bb250d909d4b72d44a
  Author: Bjorn Helgaas <email address hidden>
  Date: Sun Oct 26 18:56:04 2008 -0400

    rtc-cmos: look for PNP RTC first, then for platform RTC

    commit 72f22b1eb6ca5e4676a632a04d40d46cb61d4562 upstream

Closing this Fix Released. Please re-open this bug by marking it New if this issue is still present for you.

Changed in linux (Ubuntu):
status: New → Fix Released
Changed in linux (Ubuntu Intrepid):
status: Triaged → Fix Released
Changed in linux (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Andy Whitcroft (apw)
Changed in linux (Ubuntu Intrepid):
assignee: nobody → Andy Whitcroft (apw)
Revision history for this message
In , bingbing (bingbing-redhat-bugs) wrote :

System CMOS/real time clock driver manufacturer is (Standard system devices) and developed by Microsoft in the database contains 78 versions of the System CMOS/real time clock matches the hardware *PNP0B00.System CMOS/real time clock compatible with 1 hardwares driver contains 9 binary files, You can Download the latest drivers for your System CMOS/real time clock.
http://www.binarydb.com/driver/System-CMOS%2Freal-time-clock-340.html

Changed in linux (Fedora):
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.