From: David Brownell <david-b@pacbell.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.20-mm2
Date: Thu, 22 Feb 2007 14:17:31 -0800 [thread overview]
Message-ID: <200702221417.32626.david-b@pacbell.net> (raw)
In-Reply-To: <200702220933.37559.rjw@sisk.pl>
On Thursday 22 February 2007 12:33 am, Rafael J. Wysocki wrote:
> Unfortunately, the userland shipped with OpenSUSE refuses to talk to the new
> one (or I don't know how to make it do that).
Did your "udev" create a /dev/rtc0? If not, /sys/class/rtc-dev/rtc0/dev
will give the right major/minor numbers.
Given a /dev/rtc0, there are two simple solutions:
(a) ln -s /dev/rtc0 /dev/rtc
(b) upgrade your "hwclock" to one supporting "hwclock --file /dev/rtc0",
since that should also try rtc0 when rtc can't be opened.
I found a udev incantation "git whatchanged drivers/rtc/rtc-dev.c",
which can automate (a):
KERNEL=="rtc0", SYMLINK+="rtc"
I'm not sure what the story is on hwclock updates, given the issue
with "util-linux" maintainership. I sent a patch on 7-Aug-2006 to
Adrian Bunk, which appears to have been disregarded, then to Karel
Zak (for the new fork?) on 17-Nov-2006 ... but if there's been an
announcement about a new util-linux repository with that patch,
I missed it. The busybox patch I submitted 26-Jan-2007 hasn't
yet been merged, but that's a lot more understandable.
Basically it looks like userspace is almost a year behind the kernel
support for this RTC framework. The problematic part is that it
seems that the "util-linux" maintainership issues are preventing
that issue from getting resolved ... so for now, I usually use
workaround (a).
> > Shoot. OK, I'll see if I can reproduce it myself. Is this system
> > using a generic CMOS RTC? Or is HPET somehow involved? (That old
> > RTC driver has HPET voodoo as well as normal RTC stuff.)
>
> How can I check that?
If your boot messages say things about HPET, that's a start. :)
I don't really know HPET; it hasn't ever come up on any system
that I've used. ISTR that for various reasons BIOS would hide
it on most systems, but that Linux has been working on un-hiding
that hardware so it could be used. I'll read up on it. (As I
implied, the source code comments leave a lot to be desired.)
- Dave
next prev parent reply other threads:[~2007-02-22 22:17 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-18 5:51 2.6.20-mm2 Andrew Morton
2007-02-18 6:18 ` 2.6.20-mm2 Dave Airlie
2007-02-18 6:34 ` 2.6.20-mm2 Andrew Morton
2007-02-18 12:44 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-18 19:43 ` 2.6.20-mm2 Andrew Morton
2007-02-18 23:25 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-18 23:39 ` 2.6.20-mm2 Michal Piotrowski
2007-02-19 0:00 ` 2.6.20-mm2 Andrew Morton
2007-02-19 11:28 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-19 11:45 ` 2.6.20-mm2 Michal Piotrowski
2007-02-20 0:04 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-20 21:16 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-20 21:46 ` 2.6.20-mm2 Jeff Garzik
2007-02-20 0:43 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-20 1:20 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-20 6:31 ` 2.6.20-mm2 Andrew Morton
2007-02-20 22:12 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-18 13:06 ` 2.6.20-mm2: Oops in generic_make_request Laurent Riffard
2007-02-18 17:58 ` Mattia Dongili
2007-02-18 19:49 ` Andrew Morton
2007-02-18 20:05 ` Michal Piotrowski
2007-02-20 13:04 ` [-mm patch] fix locking in __make_request (was Re: 2.6.20-mm2: Oops in generic_make_request) Frederik Deweerdt
2007-02-19 13:34 ` Jens Axboe
2007-02-20 14:29 ` Frederik Deweerdt
2007-02-19 13:52 ` Michal Piotrowski
2007-02-19 14:08 ` Michal Piotrowski
2007-02-20 14:32 ` Frederik Deweerdt
2007-02-18 18:20 ` 2.6.20-mm2 Michal Piotrowski
2007-02-18 23:32 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-19 0:28 ` 2.6.20-mm2 Andrew Morton
2007-02-19 5:13 ` 2.6.20-mm2 David Brownell
2007-02-20 22:07 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-22 3:57 ` 2.6.20-mm2 David Brownell
2007-02-22 8:33 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-22 22:17 ` David Brownell [this message]
2007-02-23 16:36 ` 2.6.20-mm2 David Brownell
2007-03-04 22:36 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-19 18:28 ` 2.6.20-mm2 Rafael J. Wysocki
2007-02-18 23:33 ` 2.6.20-mm2: compilation fix Rafael J. Wysocki
2007-02-19 0:29 ` Andrew Morton
2007-02-19 11:33 ` Rafael J. Wysocki
2007-02-20 0:07 ` [-mm patch] fs/9p/vfs_addr.c: make 2 functions static Adrian Bunk
2007-02-20 0:54 ` Eric Van Hensbergen
2007-02-20 0:07 ` [-mm patch] drivers/mmc/Kconfig source drivers/mmc/card/Kconfig Adrian Bunk
2007-02-20 6:45 ` Pierre Ossman
2007-02-20 0:08 ` [-mm patch] drivers/video/sm501fb.c: make 4 functions static Adrian Bunk
2007-02-20 0:08 ` 2.6.20-mm2: BLOCK=n compile error Adrian Bunk
2007-02-20 0:08 ` [-mm patch] UNION_FS must depend on SLAB Adrian Bunk
2007-02-20 6:37 ` Pekka Enberg
2007-02-20 15:13 ` Josef Sipek
2007-02-21 3:07 ` [Unionfs] " hooanon05
2007-02-21 22:19 ` Andrew Morton
2007-02-22 2:00 ` Josef Sipek
2007-02-22 2:26 ` Andrew Morton
2007-02-22 3:10 ` Josef Sipek
2007-02-22 6:17 ` Pekka Enberg
2007-02-22 6:18 ` Pekka Enberg
2007-02-22 6:28 ` Josef Sipek
2007-02-22 6:42 ` Christoph Lameter
2007-02-22 2:33 ` [Unionfs] " Erez Zadok
2007-02-21 5:19 ` Josef Sipek
2007-02-20 7:39 ` 2.6.20-mm2 KAMEZAWA Hiroyuki
2007-02-20 10:06 ` 2.6.20-mm2 Andy Whitcroft
2007-02-20 11:14 ` 2.6.20-mm2 Maciej Rutecki
2007-02-20 11:38 ` 2.6.20-mm2 Maciej Rutecki
2007-02-20 21:23 ` 2.6.20-mm2: possible recursive locking detected (reiserfs-related) Rafael J. Wysocki
2007-02-20 22:48 ` Tilman Schmidt
2007-02-21 10:52 ` [-mm patch] MTD_UBI_DEBUG must depend on SYSFS Adrian Bunk
2007-02-21 10:52 ` Adrian Bunk
2007-02-21 11:57 ` [-mm patch] i386 mpparse.c: remove an unused variable Adrian Bunk
2007-02-25 13:15 ` 2.6.20-mm2 Jean Delvare
2007-02-27 20:25 ` 2.6.20-mm2 Andrew Morton
2007-02-28 9:07 ` 2.6.20-mm2 Jean Delvare
2007-02-26 22:23 ` [-mm patch] LGUEST must depend on NET Adrian Bunk
2007-02-26 23:42 ` Rusty Russell
2007-03-01 10:48 ` [-mm patch] arch/i386/xen/: possible cleanups Adrian Bunk
2007-03-01 10:53 ` Jeremy Fitzhardinge
2007-03-01 11:55 ` Adrian Bunk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200702221417.32626.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.