Adrian Hunter wrote: > I am not really sure what problem you are trying to solve.
I'm solving the problem I ran into testing variants on your patch! Some I fairly normal hardware that I have which fails reliably with the old quick code: -> tsc: Fast TSC calibration failed: code=0 i=30 j=0 d=12453,103342771544 -> tsc: Unable to calibrate against PIT -> tsc: using HPET reference calibration -> Using user defined TSC freq: 2500.210 MHz -> tsc: Detected 2500.210 MHz processor (The "code=0" is some debugging stuff I added.) And works with this: -> tsc: Fast TSC calibration using PIT: 254(12315)..159(12480) -> Using user defined TSC freq: 2500.210 MHz -> tsc: Detected 2500.210 MHz processor > I tried this patch on my problem hardware but it failed both with > ONE_BYTE_PIT set to 0 and set to 1. I am not sure it addresses the > 'really-long-latency to read the counter' problem that I have. I'm sure it *doesn't* address your problem; it's solving something else. It works if the read latency is only *sometimes* slow. If it's *always* slow (your problem), your solution or some variant would be required. > A bigger issue for my case is that "slow" calibration is not that slow, > taking only 10ms anyway which is much better than the 50ms max for so-called > "quick" calibration. I need to study how that part works and what it does. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
