Bug 11580

I think this is an FAQ, but I never remember what the A is.  I guess I 
never understood it.  David will know..

That RedHat bug suggests the issue is PNPACPI tables saying there is no RTC device (PNP0b00 etc).  I think I heard of that flavor of BIOS breakage once before.

Could you update this bug report with a tarball holding the contents of your /sys/devices/pnp* directory (and children)?  That would let me see where those resources are listed, assuming they are.  Maybe this is the same type of hardware that likes to blow past the current limits on the number of resources per PNP device, because it stuffed everything into a few generic "system" devices rather than the relevant single-device nodes...

If that kind of BIOS breakage is the issue, then a quick workaround might involve booting with "pnpacpi=off".  Also, tweaking drivers/gpio/glue.c to define ACPI_GLUE_DEBUG as 1 (not 0) should produce a boot time message "ACPI: RTC unavailable?".  And the fix will involve making that file's get_rtc_dev() have a fallback strategy like commit 1da2e3d679a8ea2d9e82040359a706da0bd3bef6 added for a slightly different problem, and having rtc-cmos know about that.

Created attachment 17840 [details]
acpi glue handles missing pnp rtc device

On the theory that the issue really is a broken ACPI device table, try this patch... it's only build tested, on one config, though.

Created attachment 17846 [details]
content of /sys/devices/pnp*

I've tried booting with pnpacpi=off as you suggested and it seems to fix it: I have a /dev/rtc0 now.

[    1.253691] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.253691] rtc0: alarms up to one day
[    1.314598] rtc_cmos rtc_cmos: setting system clock to 2008-09-18 05:53:51 UTC (1221717231)

I will try the patch in attach to see if it fixes it later today.

The /sys/devices/pnp0 contents confirm that device 00:01 seems to group lots of standard devices together ... including the rtc, not as a separate device.  One note of potential interest is that there seems to be no IRQ listed for the RTC.  :)

The patch you provided seems to fix the issue (tested with the patch applied to the Debian 2.6.26-4 kernel).

Any chances to get this into 2.6.27 (I've seen the mail on lkml but no answer or commit)? This patch fixes the issue on HP DL320G5p with vanilla 2.6.27-rc8 and is a regression (although already in the last stable kernel).

I believe that akpm has this in his 2.6.27 queue.

Reply-To: david-b@pacbell.net

> ------- Comment #9 from len.brown@intel.com  2008-10-05 21:31 -------
> I believe that akpm has this in his 2.6.27 queue.

Are you positive?  I know that I saw him forward it
to you.  Implication being that it should go through
the ACPI queue, or so it seemed to me...

- Dave

It's not in 2.6.27-rc9 FWIW, and Linus' mail did not read like he had any pending merges to do.

It would be really bad to release 2.6.27 without this fix, even though the regression was included in 2.6.26 already. The HP servers have a pretty high market share and this "bug" seems to be through the whole series.

Someone needs to come up with a different fix for the attached patch.

The two patches below (in Linus' current git tree) should fix this problem:

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

Rik and Bernhard, can you test these and report the results?  Thanks!

Works on top of vanilla 2.6.27, relevant diffs in dmesg:

 pnp: the driver 'rtc_cmos' has been registered
+rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
+rtc0: alarms up to one day, hpet irqs
 cpuidle: using governor ladder
[...]
 registered taskstats version 1
-drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+rtc_cmos rtc_cmos: setting system clock to 2008-10-15 20:15:33 UTC (1224101733)
 Freeing unused kernel memory: 480k freed

Thanks! Can this be backported to 2.6.27-stable (and maybe 2.6.26-stable) as well?

Bjorn, i've tested the two patches, it's work quite fine
but my /dev/rtc0 is created with major/minor 
crw-rw----  1 root root 254, 0 Nov 18 10:29 /dev/rtc0

shouldn't it be ?
crw-rw----  1 root root 10, 135 Nov 18 10:29 /dev/rtc0

and rtc is not added to /proc/misc
Regards
Mât

Reply-To: david-b@pacbell.net

On Tuesday 18 November 2008, bugme-daemon@bugzilla.kernel.org wrote:
> shouldn't it be ?
> crw-rw---- 

Under 2.6.28-rc6 I'm not seeing /dev/rtc* which is the same as I saw under 2.6.27*.  Booting with pnpacpi=off causes /dev/rtc0 to come back. Perhaps I'm seeing a slightly different issue than is addressed in the merged patches as I'm trying to use HPET to emulate RTC?

CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y

Hi.
I'm also having this problem on our HP BL460c nodes, with gentoo-sources-2.6.26-r4, AMD64 version, not x86.

I'll try a path I found on the web and reply back if it worked or not, as soon as I try it.

Best regards

These changes worked for me, only after I also changed rtc-cmos.c:
Please merge them.

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");

Reply-To: david-b@pacbell.net

On Wednesday 17 December 2008, bugme-daemon@bugzilla.kernel.org wrote:
> These changes worked for me, only after I also changed rtc-cmos.c:
> Please merge them.

Can't tell what you changed.  Provide a *patch* instead.
And say what kernel they're for.

Created attachment 19404 [details]
rtc.c patch

Created attachment 19405 [details]
rtc-cmos.c patch

A patch is made with "diff -u .../old.c .../new.c", and it's still not clear what kernel these apply to.

It's my understanding that *current* kernels work OK.  And thus I'm more than inclined to just mark this bug as fixed.

Is the recent noise just a request that "someone" backport the fixes to some old kernel?  Like a Gentoo one?  If so, contact the Gentoo team.

Sorry, if these are useless, I'll send the patches corrected tomorrow. Must go sleep now :)

These are against the 2.6.26 kernels, if I'm not mistaken this hasn't been fixed in more recent versions. I can also test that. Should I test against 2.6.28-rc*? Or will 2.6.27 suffice? Either way this should still be added to an updated 2.6.26 release.

Best regards

Having this issue on a Dell server using 2.6.28 (waiting for the noc to send me the make/model). /dev/rtc0 is created, but not /dev/rtc (no symlinks, either). hwclock complains of not being able to access the hardware clock via any known methods.

Will update with the model number as soon as I get it.

Created attachment 20647 [details]
rtc.c patch 2.6.26

Created attachment 20648 [details]
rtc-cmos.c patch 2.6.26

New patches for 2.6.26 added(now with diff -u). Latest stable gentoo-sources(2.6.27-r8) have this fixed, just left the patch here if someone needs/wants to add it to 2.6.26

Best regards

Has this issue been resolved upstream, or is the rtc-cmos.c patch proposed by Tiago in comment #27 still needed?

Hi John,

I believe this has been fixed upstream.

Greg KH applied the fix in a 2.6.27 stable update.

I believe the commit that fixed this is 72f22b1eb6ca5e4676a632a04d40d46cb61d4562

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

commit 72f22b1eb6ca5e4676a632a04d40d46cb61d4562 upstream

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

We shouldn't rely on "pnp_platform_devices" to tell us whether there
is a PNP RTC device.

I introduced "pnp_platform_devices", but I think it was a mistake.
All it tells us is whether we found any PNPBIOS or PNPACPI devices.
Many machines have some PNP devices, but do not describe the RTC
via PNP.  On those machines, we need to do the platform driver probe
to find the RTC.

We should just register the PNP driver and see whether it claims anything.
If we don't find a PNP RTC, fall back to the platform driver probe.

This (in conjunction with the arch/x86/kernel/rtc.c patch to add
a platform RTC device when PNP doesn't have one) should resolve
these issues:

    http://bugzilla.kernel.org/show_bug.cgi?id=11580
    https://bugzilla.redhat.com/show_bug.cgi?id=451188

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Reported-by: Rik Theys <rik.theys@esat.kuleuven.be>
Reported-by: shr_msn@yahoo.com.tw
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Thanks for the update. Closing this out.