Bug 11580

Summary: /dev/rtc entries are not created with 2.6.26+ on HP DL360
Product: Timers Reporter: rik.theys
Component: Realtime ClockAssignee: john stultz (john.stultz)
Status: CLOSED CODE_FIX    
Severity: normal CC: akpm, berni, john.stultz, j_kernel, malorent, namlas, tiagomnm
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.26, 2.6.27-rc6 Subsystem:
Regression: No Bisected commit-id:
Attachments: acpi glue handles missing pnp rtc device
content of /sys/devices/pnp*
rtc.c patch
rtc-cmos.c patch
rtc.c patch 2.6.26
rtc-cmos.c patch 2.6.26

Description rik.theys 2008-09-17 02:04:58 UTC
Latest working kernel version: 2.6.25
Earliest failing kernel version: 2.6.26
Distribution: Debian
Hardware Environment: HP DL360 G5
Software Environment: Debian Lenny amd64
Problem Description:

During boot, the rtc-cmos driver is loaded but no rtc devices are created in /dev. The hwclock command does not work as there is no device. When booting older kernels (2.6.18, 2.6.24 and 2.6.25), the devices are created. Also tried 2.6.27-rc6 but still has this issue.

Maybe related to https://bugzilla.redhat.com/show_bug.cgi?id=451188 ?

System is an HP DL360 G5.


Steps to reproduce:

1. boot a 2.6.26+ kernel
2. notice that rtc-cmos is loaded in kernel messages
3. notice that no rtcX device is created in /dev
Comment 1 Andrew Morton 2008-09-17 02:15:48 UTC
I think this is an FAQ, but I never remember what the A is.  I guess I 
never understood it.  David will know..
Comment 2 David Brownell 2008-09-17 08:45:47 UTC
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.
Comment 3 David Brownell 2008-09-17 11:29:35 UTC
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.
Comment 4 rik.theys 2008-09-17 22:56:49 UTC
Created attachment 17846 [details]
content of /sys/devices/pnp*
Comment 5 rik.theys 2008-09-17 22:57:54 UTC
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.
Comment 6 David Brownell 2008-09-17 23:39:24 UTC
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.  :)
Comment 7 rik.theys 2008-09-18 02:06:41 UTC
The patch you provided seems to fix the issue (tested with the patch applied to the Debian 2.6.26-4 kernel).
Comment 8 Bernhard Schmidt 2008-09-30 14:20:19 UTC
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).
Comment 9 Len Brown 2008-10-05 21:31:47 UTC
I believe that akpm has this in his 2.6.27 queue.
Comment 10 Anonymous Emailer 2008-10-05 22:04:20 UTC
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
Comment 11 Bernhard Schmidt 2008-10-07 03:53:10 UTC
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.
Comment 12 David Brownell 2008-10-13 16:17:47 UTC
Someone needs to come up with a different fix for the attached patch.
Comment 13 Bjorn Helgaas 2008-10-15 09:44:06 UTC
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!
Comment 14 Bernhard Schmidt 2008-10-15 13:21:12 UTC
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?
Comment 15 malorent@echo.fr 2008-11-18 03:15:15 UTC
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
Comment 16 Anonymous Emailer 2008-11-18 11:28:40 UTC
Reply-To: david-b@pacbell.net

On Tuesday 18 November 2008, bugme-daemon@bugzilla.kernel.org wrote:
> shouldn't it be ?
> crw-rw---- 
Comment 17 Joshua Hoblitt 2008-12-02 14:12:43 UTC
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
Comment 18 Tiago Marques 2008-12-14 16:55:51 UTC
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
Comment 19 Tiago Marques 2008-12-17 10:11:07 UTC
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");
Comment 20 Anonymous Emailer 2008-12-17 10:17:11 UTC
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.
Comment 21 Tiago Marques 2008-12-20 17:56:28 UTC
Created attachment 19404 [details]
rtc.c patch
Comment 22 Tiago Marques 2008-12-20 17:56:58 UTC
Created attachment 19405 [details]
rtc-cmos.c patch
Comment 23 David Brownell 2008-12-20 18:30:48 UTC
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.
Comment 24 Tiago Marques 2008-12-20 19:20:36 UTC
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
Comment 25 salman 2009-01-15 14:59:15 UTC
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.
Comment 26 Tiago Marques 2009-03-23 09:20:00 UTC
Created attachment 20647 [details]
rtc.c patch 2.6.26
Comment 27 Tiago Marques 2009-03-23 09:20:37 UTC
Created attachment 20648 [details]
rtc-cmos.c patch 2.6.26
Comment 28 Tiago Marques 2009-03-23 09:22:19 UTC
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
Comment 29 john stultz 2012-01-23 19:30:26 UTC
Has this issue been resolved upstream, or is the rtc-cmos.c patch proposed by Tiago in comment #27 still needed?
Comment 30 rik.theys 2012-01-30 13:55:09 UTC
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>
Comment 31 john stultz 2012-01-30 19:09:23 UTC
Thanks for the update. Closing this out.