on 01/11/2010 20:36 Joerg Traeger said the following:
> On Monday 01 November 2010, Andriy Gapon wrote:
>> It seems that your BIOS makes it a condition that OS supports the following
>> feature: ACPI_CAP_C1_IO_HALT.
>>
>> FreeBSD doesn't really support it, but you can try adding it to 'features'
>> variable in acpi_cpu_attach() in function in sys/dev/acpica/acpi_cpu.c;
>> look for the following line:
>> sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3;
>>
>> I don't think that should break anything for you, but may improve a thing
>> or two. I'd interested in seeing acpidump -d -t produced after the
>> patching.
> 
> Hey, est seems to be happy now!
> 
> coretemp0: <CPU On-Die Thermal Sensors> on cpu0
> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> coretemp1: <CPU On-Die Thermal Sensors> on cpu1
> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> 
> Even C2 and C3 are anounced.
> 
> dev.cpu.0.cx_supported: C1/20 C2/40 C3/60
> dev.cpu.0.cx_lowest: C3
> dev.cpu.0.cx_usage: 0.09% 2.48% 97.41% last 207us
> 
> But the system behaves strange. The fan comes up 10 times a minute and for 
> example "sh /etc/rc autoboot" runs 5 minutes now. Load is too high without 
> any processes running. And rebooting takes a long time syncing buffers. Are 
> these side effects known?

Try to not use C3.

> acpidump output did not change.

Are you 100% sure?
If yes, then could you please do the following?

$ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC
$ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl
Send me /tmp/ssdt.asl :)
-- 
Andriy Gapon
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to