[OLPC New Zealand] [Testing] Testing Summary: 19 November 2011 - Auckland, New Zealand

[James Cameron]

On Sat, Nov 26, 2011 at 01:12:38PM +1300, Tom Parker wrote:
> On Tue, 2011-11-22 at 13:13 +1100, James Cameron wrote:
> >> http://wiki.laptop.org/go/XO_1.75_B1_ECOs#RTC_Problems suggests a fix.
> > 
> > That should already have been applied to your unit, and the C1 units
> > have a switch added to the power line of the RTC, according to
> > http://wiki.laptop.org/go/XO1.75_B1_C1_Changes#Fix_RTC_Power ... so even
> > if the ECO wasn't applied on your unit, there's a chance it won't fix
> > the problem.
>  
> Both of our XO-1.75 B1 laptops are loosing the time across a reboot
> while on battery power (didn't try with AC). Last week clyde was keeping
> time but bonnie was not. 

Thanks.  That isn't surprising, given the likely change in temperature
and component age.  I saw similar unpredictability myself.

However, don't be misled by the operating system 1970 failure in the
current build os13.  #11400.  #11494.  The resultant year in the clock
is the differentiator between the software and hardware defects.  If you
see 1970, it's the software configuration problem.

You can check in extreme detail for the hardware problem using the
method in ticket #10999, which reads the RTC oscillator stop flag of the
IDT1338 chip, clears it, checks that it is cleared, then after a power
cycle check if it becomes set.

http://dev.laptop.org/ticket/10999

> I'm setting it with date -u and then hwclock --systohc. A second call to
> hwclock returns the correct time. Is this the correct way to do it?

That is one way to do it.  I use ntpdate or rdate and a network source,
but if you haven't got a network available and want to keep testing with
that unit, I think date is sufficient.

You might also set the RTC in OpenFirmware, even without network
availability.  You might put this in the /boot/olpc.fth script.

e.g.

	select /rtc decimal 13 33 00 26 11 2011 set-time

(Copied from the Fix_Clock Wiki page).

That won't fix the software problem #11400 and #11494 though.

> How do we confirm that the capacitor fix was applied? Is there a PCB
> layout I an examine, or a guide to performing the ECO?

I don't think this is worth investigating.  I've B1 units with that fix
applied, and they still forget the time.  No, the PCB layout diagram and
schematics are not public.

> > You might try some forth code to work around the problem, setting the
> > RTC to something reasonable during boot.
>  
> That will help with the certificates, but not the journal. In either
> case the fix would be overwritten by a new build.

It is true that it won't help with existing Journal entries, because the
Journal assumes the RTC is reliable.  Yes, the fix would be overwritten,
but automating the fix is possible.  Check out
http://wiki.laptop.org/go/User:Quozl/Remastering for how I do it for my
test bed; takes a .zd4 file, makes the changes I need in a controlled
fashion, and generates a new .zd file.  By having the changes
controlled, I can evaluate them in case they are suspected to have
caused a bug I'm about to report.

-- 
James Cameron
http://quozl.linux.org.au/