| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Workaround for buggy PIT
On 14 Mar 2006, at 18:05, Tomas Kopal wrote:
Well, in my case, I traced the problem down to a buggy chipset. The
VIA686a PIT timer randomly looses it's programming and needs to be
reset. The linux kernel has a workaround for this, but this does not
get
used when xen comes to play as the hypervisor takes over control of
the PIT.
I have implemented similar workaround in xen hypervisor. So far I am
running it for about three weeks now and the server is perfectly
stable.
I am interested in your comments, and I would be happy if you could
apply this patch to xen sources.
Do you have any details on what mode the timer enters when it loses its
programming, whether this affects all PIT channels, etc? The patch is
potentially okay -- it differs from Linux in that we free-run channel 2
(we don't periodically and automatically re-latch) and so the Linux
test for count > latch does not work. The test you use (diff > 2*latch)
is kind of weird, even if it does seem to work for you: I wonder what
kind of mode it enters where readings make it look like it is running
at three times normal speed?
Also, although you detect and fix up channel 2 problems, all that code
is driven off the channel 0 timer interrupt handler. What happens if
ch0 loses its programming? :-)
Really I want to understand this problem rather better before
committing a patch for a six-year-old chipset.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home