From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755090AbYICBuh (ORCPT ); Tue, 2 Sep 2008 21:50:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751239AbYICBu2 (ORCPT ); Tue, 2 Sep 2008 21:50:28 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:48325 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307AbYICBu2 (ORCPT ); Tue, 2 Sep 2008 21:50:28 -0400 Date: Tue, 2 Sep 2008 18:49:58 -0700 (PDT) From: Linus Torvalds To: Thomas Gleixner cc: Larry Finger , LKML , "Rafael J. Wysocki" , Alok Kataria , Michael Buesch Subject: Re: Regression in 2.6.27 caused by commit bfc0f59 In-Reply-To: Message-ID: References: <48BB2116.1060904@lwfinger.net> <48BC2A03.9000104@lwfinger.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Sep 2008, Thomas Gleixner wrote: > > Except for the couple of exceptions, where the readout of the old PIT > timer is broken. See arch/x86/kernel/i8253.c:pit_read() Well, the VIA problem, for example, is not an issue if you just make it do the maximum timeout (ie count down from zero), which is what you want _anyway_ in order to get the maximum range. So that one is simply avoided by just programming the timer to count the maximum possible range. However, the counter latching itself does seem to stop the counting until it is read, which is rather irritating. It means that you can't just latch and read in a tight loop. An while I actually have a patch that works very well for me, it depends on not latching, which is not strictly correct either. So yeah, I suspect using the current code and trying to just see when it isn't reliable (and the "max time" seems good for that) is probably the best option. Linus