From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 1 19:02:05 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C12B1065679 for ; Mon, 1 Nov 2010 19:02:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8188FC08 for ; Mon, 1 Nov 2010 19:02:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA27601; Mon, 01 Nov 2010 21:02:00 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4CCF0EA8.6000807@icyb.net.ua> Date: Mon, 01 Nov 2010 21:02:00 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: jt@xoasis.de References: <201011011052.11084.jt@xoasis.de> <201011011936.55934.jt@xoasis.de> <4CCF0A2A.9060506@icyb.net.ua> <201011011952.14024.jt@xoasis.de> In-Reply-To: <201011011952.14024.jt@xoasis.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: est CPU support X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:02:05 -0000 on 01/11/2010 20:52 Joerg Traeger said the following: > On Monday 01 November 2010, Andriy Gapon wrote: >> 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: on cpu0 >>> est0: on cpu0 >>> p4tcc0: on cpu0 >>> coretemp1: on cpu1 >>> est1: on cpu1 >>> p4tcc1: 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. >> Have you already tried this? What are the results? >>> acpidump output did not change. >> >> Are you 100% sure? > > Yes. > # diff acpidump.txt acpidump_acpi_patched.txt > 109c109 > < * Disassembly of /tmp/acpidump.pdLAtj, Mon Nov 1 13:38:24 2010 > --- >> * Disassembly of /tmp/acpidump.DvGKfH, Mon Nov 1 19:12:53 2010 > > >> If yes, then could you please do the following? >> >> $ dd if=/dev/mem of=/tmp/ssdt.dump bs=1 skip=0xCBE61C18 count=0x02CC > > This works. > >> $ acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > > But: > # acpidump -d -f /tmp/ssdt.dump > /tmp/ssdt.asl > Segmentation fault: 11 > >> Send me /tmp/ssdt.asl :) Can you please upload the binary file then? -- Andriy Gapon