[ltp] Massive clock drift on new thinkpad R32

[Errikos Pitsos]

Just as a follow up, we have a couple of identical tpads in the company 
2366-92G (and Us). All T30s. Unfortunately the old one I had had once 
again a defect screen from the beginning(flickering when running on 
bat), so we sent it in.
Now with this old model I never had the reported time drift problem. But 
I took a new T30, same model, setup all the BIOS parameters in the same 
way *and* just put the old HD into the new one. It boted and all stuff 
is fine, naturally.

Problem is, now I have time drift!!!

I therefore believe that this is *not* a apm problem, but a hardware 
problem:(

We will probably also send this one in. I will check it out a little 
further and then we will see.

It gave me 15mins of drift on 5h(pluged into power) standby.

erik


David Peterson wrote:
> 
> Hi All,
> 
> Further to my posts of a couple of days ago, I have narrowed down the 
> source of the bug. It appears to be the apmd package (yep, I was rather 
> surprised too!). As I mentioned, I am using debian (testing), so 
> strictly speaking this could mean the apmd package or one of its 
> dependencies, eg libapm, etc. In any case, when I disable the apm 
> modules in /etc/modules.conf and restart, the problem disappears ...
> 
> I will lodge a bug report with debian, as well as testing the latest 
> (debian/unstable) version of apmd (and deps) to see if the problem still 
> persists.
> 
> Thanks again to all those who responded for your useful help and tips.
> 
> Regards,
> 
> David Peterson
> 
> 
> 
> Tod Harter wrote:
> 
>> On Friday 22 November 2002 02:16 am, David Peterson wrote:
>>  
>>
>>> Hi Todd,
>>>
>>> When I think of changes I have made, only a couple of things readily
>>> come to mind:
>>>
>>> - upgraded from 2.4.18 kernel to 2.4.19 kernel using the debian kernel
>>> images
>>> - installed a sound driver (the i810_audio module, which also loads the
>>> soundcore module and ac97_codec module)
>>>
>>> As you can see from the following post, the system is "losing time"
>>>
>>>   
>>
>> Well, theoretically either of those changes might be involved. 
>> Technically what happens is that once Linux kernel is up and running 
>> it reads the RTC to find out what time it is and sets the 'system 
>> time'. From then on every 10 milliseconds or so the timer chip should 
>> assert a 'clock-tick' interrupt, at which point the kernel updates 
>> system time. If there is a hardware or software problem with that 
>> interrupt then naturally it would cause the kernel's concept of time 
>> to drift. Anything running in 'ring 0' (kernel or most device drivers) 
>> could easily be the culprit in missed clock-ticks, its just that 
>> GENERALLY the consequences of such problems rapidly become 
>> catastrophic, so such a bug is rare to find in a production release of 
>> any kind.
>> Given the steps you say you've taken to correct the problem I'm not 
>> sure what other advice I'd have for you. It is always possible its a 
>> hardware problem and XP simply manages to run OK by sheer chance 
>> (slightly different way it accesses hardware, etc.). It kind of feels 
>> like one of those (reinstall from scratch and hope it goes away) kind 
>> of problems (I know, I sound like MS tech support, ah well).
>>
>>  
>>
> 
> 
>