From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <78e57cf1aaa73ca03a1e3a5df2385bd8@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rio and acme scrolling
From: Richard Miller <rm@hamnavoe.com>
In-Reply-To: <466a2993c3a0232a58065be590e2a716@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Sat, 27 Mar 2004 15:22:57 +0000
Topicbox-Message-UUID: 44cde46a-eacd-11e9-9e20-41e7f4b1d025

> The clock (timer 2) speeds up by a factor of 5 or so.
> I can only assume that the firmware uses it for something
> to do with detecting the lid opening again.

This seems to be a particular problem with thinkpads - and it's
not just closing the lid: screen blanking will reset the clock
period as well.

Fixing it with timesync is not good enough, because bad things
can still happen while the clock is racing until timesync notices.
In particular, the timeout waiting for a spun-down hard drive
to come up is much too short, resulting in spurious "disk errors" -
I've lost my fossil fs twice because of this.  (Thanks to venti,
this was an irritation rather than a disaster.)

Here's the workaround I use to detect the loss of the clock period
and repair it as soon as it happens.  You'll still lose the odd
millisecond but it's better than an ongoing 5x clock overrun:

term% diff /sys/src/9/pc/i8253.c i8253.c
268c269
< 	else
---
> 	else {
269a271,278
> 		if (x > 3*MaxPeriod) {
> 			outb(Tmode, Load2|Square);
> 			outb(T2cntr, 0);		/* low byte */
> 			outb(T2cntr, 0);		/* high byte */
> 			y = 0xFFFF;
> 			x = i8253.period;
> 		}
> 	}

Alternatively, why not use the TSC when there is one?  I note that
this is the default for the MP architecture, but only for CPU server
kernels -- does anyone know why?

Here's a one-line fix which also seems to work on my thinkpad:

term% diff /sys/src/9/pc/devarch.c devarch.c
692a693
> 		archgeneric.fastclock = tscticks;

-- Richard