MIME-Version: 1.0
In-Reply-To: <20160418174855.GA1919607@devbig084.prn1.facebook.com>
References: <09c4f19409012995595db6fd0a12f326c292af1a.1460422356.git.shli@fb.com>
	<CALAqxLVAdfwni5PrXiYhLZdUY6BN1u+GiQmJouSU95g=jKBKaA@mail.gmail.com>
	<20160418173253.GA1892997@devbig084.prn1.facebook.com>
	<CALAqxLU9anpOc2L9yFk4yHuDQhDTpd7aCa3VcqH3h6B+NO0tZA@mail.gmail.com>
	<20160418174855.GA1919607@devbig084.prn1.facebook.com>
Date: Mon, 18 Apr 2016 10:54:58 -0700
Message-ID: <CALAqxLU9-ML2xAx1z6xFkiNapLfs_LZQWkJYZ_FHMxtDdmTiVA@mail.gmail.com>
Subject: Re: [RFC 1/2] time: workaround crappy hpet
From: John Stultz <john.stultz@linaro.org>
To: Shaohua Li <shli@fb.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
        calvinowens@fb.com
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 922
Lines: 21

On Mon, Apr 18, 2016 at 10:48 AM, Shaohua Li <shli@fb.com> wrote:
> On Mon, Apr 18, 2016 at 10:42:38AM -0700, John Stultz wrote:
>> I'm sort of on the edge of just adding a blacklist entry for the HPET
>> on this hardware. I'm not sure its something that can be easily
>> handled generically.   I *hope* you only see this issue on one sort of
>> hardware?
>
> Blacklist is a option for sure. We saw the issue in several machines,
> but seems they are the same type. I hope we can have a defensive way to
> handle such problem if it happens in other hardware.

Yea. I'm not sure what can be done. Filtering -1 values from the HPET
seems problematic for latency reasons. I'm not sure we should punish
all the fine hardware w/o the issue just to try to detect the case
where its bad.

Especially as this is something particularly problematic to detect
separately from other more common well known bad hardware.

thanks
-john