Iain Hibbert wrote:
> On Mon, 11 Sep 2006, Kurt Schreiner wrote:
>
>   
>> On Mon, Sep 11, 2006 at 11:37:02AM -0700, Garrett D'Amore wrote:
>>     
>>> Take a look at arch/x86/isa/clock.c, maybe you can dump the dates being
>>> reported there?
>>>       
>> Hi, had the same problem and did some investigation and put some printfs
>> at "the right place":
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_mon = 9
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_day = 11
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_wday = 248
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_hour = 12
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_min = 36
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: dt.dt_sec = 46
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: WARNING: preposterous TOD clock time
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: tv.tv_sec = 1157978134 secs
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: WARNING: using filesystem time
>> Sep 11 14:35:36 ipaddi-bsd /netbsd: WARNING: CHECK AND RESET THE DATE!
>>
>> The problem is "dt.dt_wday = 248". Taking this "sanity check" out get's things
>> going again.
>>     
>
> Ok, I didnt do that but looking at rtc_get_ymdhms() in
> arch/x86/isa/clock.c, dt_wday is not being set, so either it should be, or
> todr_gettime() should memset(&dt, 0, sizeof(dt)) before the call?
>
> iain
>   

I just removed the check for it.  The member is never actually used.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191