ts-7000
[Top] [All Lists]

[ts-7000] Re: setting system clock on 2.6.29

To:
Subject: [ts-7000] Re: setting system clock on 2.6.29
From: "j.chitte" <>
Date: Tue, 16 Jun 2009 20:05:25 -0000
--- In  Christian Gagneraud <> wrote:
>
> j.chitte wrote:
> > --- In  Petr ©tetiar <ynezz@> wrote:
> >> j.chitte <j.chitte@> [2009-06-14 05:36:20]:
> >>
> >>> Hi,
> >> Hi,
> >>
> >>> I have a 7250 with the ts optional RTC . In the boot log I'm seeing this:
> >>>
> >>> ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx as rtc0
> >>> rtc-m48t86 rtc-m48t86: rtc core: registered m48t86 as rtc1
> >>> rtc-m48t86 rtc-m48t86: battery ok
> >>> Registered led device: green
> >>> Registered led device: red
> >>> ...
> >>> rtc-m48t86 rtc-m48t86: setting system clock to 2009-06-14 05:17:03 UTC 
> >>> (1244956623)
> >>>
> >>> good, but then ...
> >>>
> >>> mounting local filesystems (in fstab)
> >>> setting system clock
> >>> Thu Jan  1 00:00:57 UTC 1970
> >>>
> >>>
> >>> Now I could remove the on-chip rtc since it is pretty redundant but what
> >>> process is resetting to system clock to zero?
> >> You can remove on-chip RTC in you kernel config. It's on-chip RTC resetting
> >> system clock to "zero". Or you can set rtc1 as default rtc using 
> >> RTC_HCTOSYS_DEVICE
> >> kernel config option.
> >>
> >> -- ynezz
> >>
> >
> > thanks for the reply. However, that is not what is happening. You will note 
> > from my post that it is RTC1 that is used to set the system clock since I 
> > have already enable the option you indicated.
> >
> > My question remains : what process is coming in later and resetting the 
> > system clock to RTC0 ?
>
>
> grep -r "rtc" /etc
> to catch any conf file or init script dealing with RTC
> or
> grep -ri "setting system clock" /etc/rc*
> to catch the init script that display you this mesage
>
> Obviously one of your init script is using the wrong rtc device, again
> remove ep93xx-rtc from kernel and everything will be fine, you don't
> need two RTC.
>
> Which distro are you running?
>
> Chris
>
> >

Thanks, a bit of grepping found the culprit in rcS.sysinit. I should have 
thought of doing that. I had a reference to /proc/driver/rtc that was 
presumable the on-chip rtc when it was there as rtc0.

I had already binned it but wanted to find out what bit of cruft was causing it 
to happen. No sense in setting the clock twice even if it gets it right.

just ignoring it once I had removed the second rtc did not please me. I don't 
like ostrich engineering. These things turn round and bite on day. Usually when 
you're on another continent.

many thanks helping me find the culprit.





------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
    
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU