Date: Fri, 19 Nov 2010 15:30:15 +0200 From: Andriy Gapon <avg@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-stable@freebsd.org, "Alexandre \"Sunny\" Kovalenko" <gaijin.k@ovi.com>, John Baldwin <jhb@freebsd.org> Subject: Re: Console options for legacy-free mini-itx server? Message-ID: <4CE67BE7.2000305@freebsd.org> In-Reply-To: <20101119135414.A39988@sola.nimnet.asn.au> References: <20101115045549.GB96011@johnny.reilly.home> <201011180759.39129.jhb@freebsd.org> <985E77DE-BFC9-4186-8493-36C63C62CE29@bigpond.net.au> <201011181711.05440.jhb@freebsd.org> <20101119135414.A39988@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
on 19/11/2010 05:14 Ian Smith said the following: > On Thu, 18 Nov 2010, John Baldwin wrote: > > On Thursday, November 18, 2010 4:07:27 pm Andrew Reilly wrote: > > > Hi John, > > > > > > On 18/11/2010, at 23:59 , John Baldwin wrote: > > > > > > > You used devinfo -v, so it shows the devices that exist even if they failed > > > > to attach. Try just using 'devinfo' and seeing if est1 still shows up. > > > > > > OK, you're right: running without -v shows only est0: > > > > > > nexus0 > > > apic0 > > > ram0 > > > acpi0 > > > cpu0 > > > acpi_perf0 > ^^^^^^^^^^ > > > est0 > > > p4tcc0 > > > cpufreq0 > > > cpu1 > > > p4tcc1 > > > cpufreq1 > > > acpi_button0 > > > pcib0 > > > <...> > > > > > > Is est. involved in the reboot question? > > > > Probably not. > > I'm not so sure, having just noticed something that I missed last time: > > device_attach: acpi_perf1 attach returned 6 > est0: <Enhanced SpeedStep Frequency Control> on cpu0 > p4tcc0: <CPU Frequency Thermal Control> on cpu0 > device_attach: acpi_perf1 attach returned 6 > est1: <Enhanced SpeedStep Frequency Control> on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 16 > device_attach: est1 attach returned 6 > p4tcc1: <CPU Frequency Thermal Control> on cpu1 > > I'd mis-read or assumed that first line as being for acpi_perf0, rather > than an earlier? attempt to attach acpi_perf1 at that time. > >>From cpufreq(4): > > The following device drivers offer absolute frequency control via the > cpufreq interface. Usually, only one of these can be active at a time. > > acpi_perf ACPI CPU performance states > est Intel Enhanced SpeedStep > ichss Intel SpeedStep for ICH > powernow AMD PowerNow! for K7 and K8 > smist Intel SMI-based SpeedStep for PIIX4 > > Apart from never having seen est0 attach but est1 not, my understanding Very likely that it could be a BIOS bug. My guess is that DSDT defines _PSS method in one processor object, but not in the other, > from both the manual and from having read some of the code over the time > is that acpi_perf0 should only attach if eg est0 didn't - is that wrong? To some degree :-) On most modern systems acpi_perf attaches in "information only" mode where it provides P-state information to a driver like est or hwpstate that performs actual P-state switching. In some cases acpi_perf may work in fill mode. In other other cases a hardware-specific driver like est can work without acpi_perf. > Note also that there's no mention of acpi_perf0 attaching in the dmesg, > where I'm used to seeing that listed (eg as with my P3-Mobile CPU) -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE67BE7.2000305>