Console options for legacy-free mini-itx server?

[Andriy Gapon]

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