On Thu, 7 Apr 2016, Andy Lutomirski wrote: > Allowing user code to map the HPET is problematic. HPET > implementations are notoriously buggy, and there are probably many > machines on which even MMIO reads from bogus HPET addresses are > problematic. > > We have a report that the Dell Precision M2800 with: > > ACPI: HPET 0x00000000C8FE6238 000038 (v01 DELL CBX3 01072009 AMI. 00000005) > > is either so slow when accessing the HPET or actually hangs in some > regard, causing soft lockups to be reported if users do unexpected > things to the HPET. > > The vclock HPET code has also always been a questionable speedup. > Accessing an HPET is exceedingly slow (on the order of several > microseconds), so the added overhead in requiring a syscall to read > the HPET is a small fraction of the total code of accessing it. > > To avoid future problems, let's just delete the code entirely. > > In the long run, this could actually be a speedup. Waiman Long as a > patch to optimize the case where multiple CPUs contend for the HPET, > but that won't help unless all the accesses are mediated by the > kernel. > > Cc: Waiman Long <waiman.l...@hpe.com> > Reported-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> > Signed-off-by: Andy Lutomirski <l...@kernel.org>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
