Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: slow clock on DELL Latitude 5501



On 2020/04/22 4:49, Joerg Sonnenberger wrote:
On Fri, Apr 17, 2020 at 12:05:25AM +0900, SAITOH Masanobu wrote:
Hi, all.

On 2020/02/13 20:10, is%netbsd.org@localhost wrote:
On Tue, Feb 11, 2020 at 05:34:58PM +0100, Frank Kardel wrote:
clockinterrupt be 4 times too slow explains the high TSC frequency(*4) and
ACPI-Fast and hpet0 seem the have the same frequency scaling as
clockinterrupt.

So it loock like the clockinterrupt setup is botched.

Possibly related:

* after a reboot, our (efi)boot doesn't count down.
* after a single powerdown in this condition, boot counts down,
   netbsd kernel boots, but hangs after the internal ubt (last
   device) has attached.
* needs a 2nd powerdown in this condition to boot again.

(after shutdown -p and powerup , boots ok)

	-is


Please test the following (work-in-progrss) diff:

	http://www.netbsd.org/~msaitoh/tsc-20200416-2.dif

I bought a new Intel NUC(BXNUC10I3FNK (Comet Lake U)) and it had the same problem.

This seems to be quite the wrong direction. What seems to be the problem
here is that the i8254 is jut fubar. It's what the use to calibrate all
other timers again though. I don't like using the MSRs at all, they are
very notorious for providing nonsense. I think what we can do is make
sure that the ACPI timer or HPET is available much earlier and then use
that one.

I agree to detect HPET much earlier. Please someone(TM) do it.

I heard that future Intel chips have no legacy device support which
include i8254 timer, so we must do it in (near?) future.

It is both faster and has a higher precision than the i8254.

Joerg



--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)


Home | Main Index | Thread Index | Old Index