on 25/07/2011 21:55 Jung-uk Kim said the following:
> powernow expects a static table
> (via acpi_perf) but _PSS is dynamically constructed at runtime. I
> don't think we can support this case easily, sorry.
Just a side note.
Actually I do not see anything wrong with that _PSS except that ASL
On Saturday 23 July 2011 04:47 am, Jeremy Chadwick wrote:
> On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote:
> > On 22Jul11 08:16, John Baldwin wrote:
> > }The problem is that we calibrate the TSC using this algorithm:
> > }
> > } - grab the TSC
> > } - spin on the ISA timer waiting f
On 25Jul11 14:55, Jung-uk Kim wrote:
}I agree that the legacy USB issue must be fixed but your BIOS is more
}broken than I originally thought. powernow expects a static table
}(via acpi_perf) but _PSS is dynamically constructed at runtime. I
}don't think we can support this case easily, sorry.
On Saturday 23 July 2011 04:21 am, Callum Gibson wrote:
> On 22Jul11 17:57, Jung-uk Kim wrote:
> }Please try the attached patch. If it doesn't work, I need to see
> }"acpidump -dt" output.
>
> Sorry, no difference. Given jhb's response is there any point
> pursuing this further? Seems to be a "kno
On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote:
> On 22Jul11 08:16, John Baldwin wrote:
> }The problem is that we calibrate the TSC using this algorithm:
> }
> } - grab the TSC
> } - spin on the ISA timer waiting for it to run for a second
> } - grab the TSC
> }
> }The issue is that
On 22Jul11 17:57, Jung-uk Kim wrote:
}Please try the attached patch. If it doesn't work, I need to see
}"acpidump -dt" output.
Sorry, no difference. Given jhb's response is there any point pursuing
this further? Seems to be a "known issue" with legacy usb that perhaps
can't be fixed.
In any cas
On 22Jul11 08:16, John Baldwin wrote:
}The problem is that we calibrate the TSC using this algorithm:
}
} - grab the TSC
} - spin on the ISA timer waiting for it to run for a second
} - grab the TSC
}
}The issue is that the SMI# fires at the same time we want to be execuiting
}step 3, and step 3 i
On Friday 22 July 2011 07:13 am, Callum Gibson wrote:
> On 21Jul11 17:53, Jung-uk Kim wrote:
> }>
> }>
> http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
> }> and dev.cpu.0.freq reappears! Spooky. Is that a solution or a }>
> workaround? I noticed this disables usb keyboard suppo
On Thursday, July 21, 2011 5:43:10 pm Jeremy Chadwick wrote:
> On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote:
> > On 21Jul11 12:07, Jung-uk Kim wrote:
> > }Can you please do "set debug.cpufreq.verbose=1" from loader prompt and
> > }show me the dmesg output? I want to see intial se
On 21Jul11 17:53, Jung-uk Kim wrote:
}>
}> http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out
}> and dev.cpu.0.freq reappears! Spooky. Is that a solution or a
}> workaround? I noticed this disables usb keyboard support at the
}> boot menus.
}
}It is a workaround. Please try the at
On Thursday 21 July 2011 04:56 pm, Callum Gibson wrote:
> On 21Jul11 12:07, Jung-uk Kim wrote:
> }Can you please do "set debug.cpufreq.verbose=1" from loader prompt
> and }show me the dmesg output? I want to see intial settings. You
> can }reset it from command line with "sysctl
> debug.cpufreq.v
On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote:
> On 21Jul11 12:07, Jung-uk Kim wrote:
> }Can you please do "set debug.cpufreq.verbose=1" from loader prompt and
> }show me the dmesg output? I want to see intial settings. You can
> }reset it from command line with "sysctl debug.cp
On 21Jul11 12:07, Jung-uk Kim wrote:
}Can you please do "set debug.cpufreq.verbose=1" from loader prompt and
}show me the dmesg output? I want to see intial settings. You can
}reset it from command line with "sysctl debug.cpufreq.verbose=0"
}later.
http://members.optusnet.com.au/callumgibson/
On Wednesday, July 20, 2011 10:28:19 pm Callum Gibson wrote:
> On 20Jul11 19:28, Jung-uk Kim wrote:
> }From your dmesg output, I see that the processor speed was not
> }calibrated properly. ML-40's max. core freq. is 2,200 MHz according
> }to its specification but it was probed at 2,282 MHz, whi
On Wednesday 20 July 2011 10:28 pm, Callum Gibson wrote:
> On 20Jul11 19:28, Jung-uk Kim wrote:
> }From your dmesg output, I see that the processor speed was not
> }calibrated properly. ML-40's max. core freq. is 2,200 MHz
> according }to its specification but it was probed at 2,282 MHz,
> which i
On 20Jul11 19:28, Jung-uk Kim wrote:
}From your dmesg output, I see that the processor speed was not
}calibrated properly. ML-40's max. core freq. is 2,200 MHz according
}to its specification but it was probed at 2,282 MHz, which is too
}high. I think that's the problem. Can you please try th
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
> Hi,
> I've just noticed and tracked down a regression in
> x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
>9.html
>
> although no followup seems to hav
On 19Jul11 12:04, Jung-uk Kim wrote:
}On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
}> I've just noticed and tracked down a regression in
}> x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
}>
}> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
}>9.html
On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote:
> Hi,
> I've just noticed and tracked down a regression in
> x86/cpufreq/powernow.c (on amd64) which was first mentioned here:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350
>9.html
>
> although no followup seems to hav
Hi,
I've just noticed and tracked down a regression in x86/cpufreq/powernow.c
(on amd64) which was first mentioned here:
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023509.html
although no followup seems to have occurred.
Symptoms are that powerd stops working because the dev.c
20 matches
Mail list logo
