Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1381953

Re: [RFC 1/2] time: workaround crappy hpet

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [RFC 1/2] time: workaround crappy hpet John Stultz <john.stultz@linaro.org> - 2016-04-18 19:10 +0200
  Re: [RFC 1/2] time: workaround crappy hpet Shaohua Li <shli@fb.com> - 2016-04-18 19:40 +0200
    Re: [RFC 1/2] time: workaround crappy hpet John Stultz <john.stultz@linaro.org> - 2016-04-18 19:50 +0200
      Re: [RFC 1/2] time: workaround crappy hpet Shaohua Li <shli@fb.com> - 2016-04-18 19:50 +0200
        Re: [RFC 1/2] time: workaround crappy hpet John Stultz <john.stultz@linaro.org> - 2016-04-18 20:00 +0200

csiph-web