ThinkPad X60: select() to /dev/rtc to wait for clock tick timed out
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| linux-source-2.6.15 (Ubuntu) |
High
|
Unassigned | ||
| linux-source-2.6.17 (Baltix) |
Undecided
|
Unassigned | ||
| linux-source-2.6.17 (Ubuntu) |
Undecided
|
Ben Collins | ||
| util-linux (Debian) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Dapper seems unable to read or set my RTC on an IBM/Lenovo X60 thinkpad.
The BIOS shows the hardware clock to be several hours different to the
Linux clock. When the network comes up, the screensaver appears to kick
in because the ntpdate moves the system clock to bring it up to date.
There are other symptoms:
peregrine% sudo
hwclock ~
select() to /dev/rtc to wait for clock tick timed out
affects /distros/ubuntu
:
description: | updated |
Jonathan Hitchcock (vhata) wrote : | #1 |
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 43661] Re: ThinkPad X60: select() to /dev/rtc to wait for clock tick timed out | #2 |
So this is not just laptop-specific?
importance high
Changed in linux-source-2.6.15: | |
importance: | Medium → High |
Ben Collins (ben-collins) wrote : | #3 |
Can you try running "hwclock --directisa" and see if that works?
Also "dmesg | grep -i rtc" and "lsmod | grep rtc" outputs would be useful.
Thanks
Changed in linux-source-2.6.15: | |
status: | Unconfirmed → Needs Info |
Mark Shuttleworth (sabdfl) wrote : | #4 |
peregrine%
hwclock ~
Fri 23 Jun 2006 18:52:23 BST -0.007185 seconds
peregrine% hwclock
--directisa ~
hwclock is unable to get I/O port access: the iopl(3) call failed.
Probably you need root privileges.
peregrine% sudo hwclock
--directisa ~
Fri 23 Jun 2006 18:52:28 BST -0.057272 seconds
peregrine% sudo /etc/init.
stop ~
peregrine%
So, it seems to be working fine now for me, though I know others are
still having the problem.
Mark
lix (lix-lix) wrote : | #5 |
--directisa option works for me! (IBM thinkpad x60 also).
root@foo:/home/bar# hwclock --directisa -w
root@foo:/home/bar# hwclock --directisa -r
Wed 12 Jul 2006 13:10:36 CEST -0.494677 seconds
lg, a
Mark Shuttleworth (sabdfl) wrote : | #6 |
Interesting. I get the same results from hwclock -r and -w, with or
without --directisa. And this bug does not seem to appear on my system
any more. Is there any way to fix the system so that it knows when to
use directisa?
Mark
Baishampayan Ghose (b.ghose) wrote : | #7 |
I can reproduce the bug on my Dell XPS m1210 laptop. --directisa fixes it though it still consumes quite a bit of CPU and time while it works.
And in my case, `hwclock --directisa --show` gives no output.
Ben Collins (ben-collins) wrote : | #8 |
Not the same bug.
Changed in util-linux: | |
status: | Unconfirmed → Rejected |
Changed in linux-source-2.6.17: | |
status: | Unconfirmed → Rejected |
Ben Collins (ben-collins) wrote : | #9 |
Seems this is fixed in edgy.
Mark, thanks for the use of the laptop t test.
Changed in linux-source-2.6.17: | |
assignee: | nobody → ben-collins |
status: | Unconfirmed → Fix Released |
vrodic (vedran-vodatel) wrote : | #10 |
Ben, how do you think this was fixed?
I'm on Debian using x60, and I've tried running various ubuntu kernels, but without any change. The only thing that helped was editing the init.d/hwclock.sh script and HWCLOCKPARS=
vrodic (vedran-vodatel) wrote : | #12 |
additional info to my last comment
List of kernels I've tried
ubuntu kernels
linux-image-
linux-image-
custom built
linux-image-
debian kernels
linux-image-
vrodic (vedran-vodatel) wrote : | #13 |
I've just teste the 2.6.20-2 ubuntu package, with same results when running hwclock.
the bios on this laptop is latest 2.06
Launchpad Janitor (janitor) wrote : | #14 |
[Expired for linux-source-2.6.15 (Ubuntu) because there has been no activity for 60 days.]
I can confirm this on an Intel dual core Pentium. I synchronized my clock with an NTP server on Friday, and started up NTP, which should have kept it in sync. I rebooted today (Sunday) to install a video card, and my clock is several hours wrong again - I suspect because it got set from the hwclock, and NTP won't correct it by such a big jump. I can't query the hwclock, though, with the same error as above:
$ sudo hwclock
select() to /dev/rtc to wait for clock tick timed out