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: 77+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome