Hello,
On Monday, October 1, 2007 at 17:38:23 +0200, Alain Guibert wrote:
We can also try to make adjtimex less sensible to system load. The
first step on this path [is commited into 1.23]
Now a small second step: The first timestamp in a serie is less accurate
than the following ones
Hello Jim,
On Friday, April 4, 2008 at 22:34:40 -0400, James R. Van Zandt wrote:
One a Sony Vaio VGN-TXN27N, adjtimex hangs when run as
adjtimex -c --verbose
opened /dev/rtc for reading
waiting for CMOS update-ended interrupt
And discussing bug #460065 on Friday, April 4, 2008
Hello Paul,
On Thursday, April 10, 2008 at 9:42:45 +0200, Paul Menzel wrote:
I am experiencing this problem, too.
It can be a hardware bug, a kernel bug, or something else. What is your
computer exactly? And what is the output of:
| # hwclock --rtc=/dev/rtc0 --debug
Since some people say,
On Friday, April 11, 2008 at 20:18:10 +0200, Michael Grosser wrote:
| # hwclock --rtc=/dev/rtc0 --debug
hwclock: unrecognized option `--rtc=/dev/rtc0'
Indeed this old hwclock from util-linux-2.12r didn't have this option.
However you can instead make /dev/rtc a symlink to rtc0, temporarily
Hello Michael,
On Wednesday, April 9, 2008 at 10:58:23 +0200, Michael Grosser wrote:
On a chip set NVIDIA nForce 630a the commans hwclock --show
produces the output select() to /dev/rtc to wait for clock tick
timed out.
It can be a hardware bug, a kernel bug, or something else. What is the
Hello Matteo,
On Thursday, April 3, 2008 at 16:39:02 +0200, Matteo SISA wrote:
a Dell Latitude 120L laptop [...]
# hwclock --show
select() to /dev/rtc to wait for clock tick timed out
I don't know this machine, so it depends: either you are lucky to get
a better support (and perhaps even
package adjtimex
retitle 471203 adjtimex: --directisa segfaults on armel
thanks
On Monday, March 24, 2008 at 12:38:59 +0100, Tobias Frost wrote:
The no-interrupts-fallback seems to do the trick
Excellent, thank you for checking those patches.
I could not try the rtc0-fallback, as the
no-interrupt-fallback.patch.
Alain.
fallback to /dev/rtc0 when /dev/rtc fails
Signed-off-by: Alain Guibert [EMAIL PROTECTED]
diff -prud adjtimex-1.23.orig/adjtimex.c adjtimex-1.23/adjtimex.c
--- adjtimex-1.23.orig/adjtimex.c Sat Mar 22 10:28:25 2008
+++ adjtimex-1.23/adjtimex.cSat Mar 22 15:09
On Friday, February 8, 2008 at 16:04:08 +0100, Alain Guibert wrote:
Method #3 (second_change) is clean, and usable by non-root users if
they have read rights on /dev/rtc. Accuracy is a little bit less good
on good kernels, catastrophic on bad kernels.
Bug #471203 revealed that the adjtimex
On Tuesday, March 18, 2008 at 22:41:24 +0100, Tobias Frost wrote:
Unfortuantly strace is not available on lenny. I Will install ist from
sid, and then send the strace log too.
Much thanks, it helps:
| open(/dev/port, O_RDWR) = 3
| lseek(3, 112, SEEK_SET) = 112
|
Hello Tobias,
On Sunday, March 16, 2008 at 17:53:44 +0100, Tobias Frost wrote:
When installing -- or invoking manually -- adjtimex segfaults on
lenny/armel.
Thank you for reporting. Could you please try if it works calling:
| # adjtimex --compare=1 --directisa
Please also show us the
On Sunday, February 3, 2008 at 23:44:18 +0100, Alain Guibert wrote:
-3) Rename busy_wait() to busywait_uip_fall() only for --directisa
mode. Write a new busywait_second_change() function only for /dev/rtc
mode, looping around ioctl(RTC_RD_TIME) until the time changes.
The attached
Hello,
On Thursday, May 12, 2005 at 16:33:55 +0200, Alain Guibert wrote:
Adjtimex --review suggests a little inaccurate RTC adjustement (to put
in /etc/adjtime): That needs to be expressed in seconds per day of
CMOS time. Not of reference time, nor somewhere in between.
The attached patch
Hello Drew,
On Wednesday, February 6, 2008 at 14:43:08 +1100, Drew Parsons wrote:
the server list could be read in from a separate file,
/etc/ntp.servers say. This could be done either as an #include
mechanism reading /etc/ntp.conf (bug #370332 says this does not yet
exist)
Note that
On Sunday, February 3, 2008 at 23:44:18 +0100, Alain Guibert wrote:
-1) Rewrite busy_wait() to make it work in whatever using_dev_rtc
mode, decouple cmos_fd for rtc and port, and fix some other minor
probs.
The attached patch implements this proposal. Klaus: Could you please
check
Hello Klaus and Jim,
On Saturday, February 2, 2008 at 14:02:23 +0100, Klaus Ethgen wrote:
/dev/rtc doesn't allow user access to update interrupts
- using busy wait instead
Understood: This is printed when ioctl(RTC_UIE_ON) fails, because the
kernel driver thinks that the interrupt is not
Hello, a quick erratum:
On Wednesday, September 19, 2007 at 17:39:04 +0200, Alain Guibert wrote:
[When the RTC update interrupt cannot be enabled] the fallback method
(busywait for change of time) seems to be much less accurate than with
--directisa itself (busywait for UIP fall). Testing
Hello Ondrej, Martin, David, and Paul.
On Thursday, September 20, 2007 at 11:20:15 +0200, Ondrej Certik wrote:
[bugs #435102, #439593, and #450686]
[hwclock timeouts waiting for RTC interrupt]
Where is the real problem, that it doesn't work for me without the
--directisa? Is
with other RTC date values, but is only simply
incremented at midnight. The day meant is in the eye of the reader,
which nearly always just ignores the value. Most common assumption is
that 1 means Sunday.
Signed-off-by: Alain Guibert [EMAIL PROTECTED]
diff -prud adjtimex-1.22.orig/adjtimex.c
machines
the ioctl(RTC_UIE_ON) succeeds.
Alain.
Timestamp the tick of the CMOS clock at the closest possible,
for better accuracy and lower dispersion of measures.
Signed-off-by: Alain Guibert [EMAIL PROTECTED]
diff -prud adjtimex-1.22/adjtimex.c adjtimex-1.22.mod/adjtimex.c
--- adjtimex-1.22
On Tuesday, September 25, 2007 at 1:27:12 +0200, Ondrej Certik wrote:
hwclock: Open of /dev/rtc failed, errno=16: Device or resource busy.
Using direct I/O instructions to ISA clock.
This case works, as hwclock automatically fallbacks to --directisa by
itself. However the script can't guess
On Tuesday, September 25, 2007 at 13:42:36 -0600, LaMont Jones wrote:
-rw-r--r-- root/root 2916 2007-09-21 22:12
./usr/share/doc/util-linux/README.Debian.hwclock
I see no .gz on that file as delivered. There was previously, and now
there is not.
Ok, I had not noticed.
When I was
bugs #435102 and
#439593).
Alain.
fixes 3 minor quirks in hwclock.sh 2.13-7
see Debian bug #443487
Signed-off-by: Alain Guibert [EMAIL PROTECTED]
--- ulng-7/debian/hwclock.sh.orig Tue Sep 25 13:37:30 2007
+++ ulng-7/debian/hwclock.shTue Sep 25 14:20:29 2007
@@ -12,7 +12,7
On Thursday, September 20, 2007 at 11:20:15 +0200, Ondrej Certik wrote:
Where is the real problem, that it doesn't work for me without the
--directisa? Is it a kernel problem, or a hardware problem?
Well, I don't know. There are several possible scenarios. Maybe a
misdesigned RTC chip
Package: adjtimex
Version: 1.21.1-3
Severity: normal
Tags: patch
Hello,
Reportedly, on some machines, adjtimex hangs with the /dev/rtc driver,
because ioctl(RTC_UIE_ON) succeeds, but no interrupt never comes. The
attached patch adds a --directisa option to adjtimex, named after the
hwclock
Hello Ondrej,
On Tuesday, September 11, 2007 at 14:50:54 +0200, Ondrej Certik wrote:
HWCLOCKPARS=--directisa
How about using this by default so that I don't have to make this
change manually?
The --directisa RTC access method has some drawbacks:
- It wastes processor cycles by
On Monday, September 3, 2007 at 15:55:14 +0100, David wrote:
I *think* that, in a computer with Windows and Linux, the time must be
saved in the hardware.
Well no, it's not linked. The time should be written to the hardware
clock in any case.
# hwclock --systohc
select() to /dev/rtc to
Hello David,
On Saturday, August 25, 2007 at 20:52:32 +0100, David wrote:
I have a dual boot with Windows Vista, so I need the option
HWCLOCKPARS=--directisa in /etc/init.d/hwclock.sh.
There is a link between the Vista dual boot and hwclock --directisa?
I thought this option was only for
On Wednesday, September 13, 2006 at 8:06:40 +0200, Petter Reinholdtsen wrote:
I do realise that hwclock have its purpose if the hardware clock is
using local time, and not UTC, but am not equally convinced that it is
useful if it is using UTC.
What about drift correction? The RTC chip of my
Hello Petter,
On Monday, September 11, 2006 at 22:41:24 +0200, Petter Reinholdtsen wrote:
a lot of time is spent in hwclockfirst.sh and hwclock.sh. Dropping
these from the boot reduced the boot time from 44 to 28 seconds.
Are you sure? They are supposed to take between 1 and 2 seconds.
Package: radioclk
Version: 1.0-1
Severity: important
Hello,
When the offset between system time and radio time is around an integer
number of seconds, radioclkd 1.0 wrongly calculates the offset to the
nearest plain second.
Examples:
- If the real offset is +950 ms, radioclk will put into
Hello Yann,
On Friday, October 4, 2002 at 3:43:47 PM +0200, Yann Droneaud wrote:
I usualy use the local clock (RTC) as a fallback synchronization
source. This source is quite always available on all computers, but
should only use by ntpd if this clock is not modified by hands and set
to
Package: adjtimex
Version: 1.20-5
Severity: normal
Adjtimex --review suggests a little inaccurate RTC adjustement (to put
in /etc/adjtime): That needs to be expressed in seconds per day of CMOS
time. Not of reference time, nor somewhere in between.
Example with this test-clocks.log file:
|
Package: adjtimex
Version: 1.20-5
Severity: normal
Tags: upstream
Hello,
That's not a Debian package, but an upstream bug. And upstream BTS is
right here, isn't it? On old systems without linux/rtc.h, making version
1.20 of adjtimex gives:
| cc -g -O2 -Wall -I. -DVERSION=\1.20\ -o adjtimex
Package: adjtimex
Version: 1.16-1
Severity: normal
Hello,
Reading the localtime hardware clock with adjtimex is false by one hour
when a to-DST or back transition occured since last CMOS clock write.
Example here CMOS was last set (with hwclock 2.23) on March 22 CET +0100
winter time, and still
35 matches
Mail list logo
