On Mon, Nov 11, 2013 at 10:56 AM, Andy <[email protected]> wrote: > On Fri 08 Nov 2013 18:28:38 GMT, Chris Cappuccio wrote: > >> Andy [[email protected]] wrote: >> >>> Hi Chris, >>> >>> Yea that makes sense, as you say its pretty trivial and a divide by zero >>> check is a common coding practice... >>> >>> I will try again as I only tried 'Max Performance' but it might mean >>> until >>> this is fixed we cannot enable 'Turbo+' at all. >>> >>> With the GIANT lock in OpenBSD I was really hoping that Turbo+ would >>> work as >>> that gives me a few hundred extra MHz on top of the default 3.5GHz Ivy >>> clock >>> in a single core etc. >>> >>> Please let me know if a commit for this is done and I will test using a >>> snapshot :) >>> >>> Thanks for your time, Andy. >>> >>> >> My patch is almost certainly not the right solution. But it will >> possibly allow you to boot in turbo mode. >> >> So, it might be interesting to try it, or to try a version >> with the patch (to get a turbo mode dmesg for phessler) and also >> some extra info like: >> >> printf("high: %d low: %d cpuspeed %d\n",high,low,cpuspeed); >> >> in the est_init() function after high and low are calculated >> (of course). >> >> Perhaps the way that the est_fqlist is built is faulty >> for new CPUs, dmesg output from this might show this. >> >> For some reason I thought I had a Xeon 55xx but it's actually >> an E5-26xx, and not a v2 either. And doesn't show this >> problem as far as I can tell. Maybe I need to test it more! >> > > Ok, I'll have a go at writing the fix and test it, but expect some pretty > newbie questions.. > > It's been a /very/ long time since I've written any C and I've never tried > to compile OpenBSD. > > I'll read http://www.openbsd.org/faq/faq5.html next weekend.. >
and man release .......
