From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 11 11:06:57 2011 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 88DD0106566B for ; Mon, 11 Jul 2011 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 77FCA8FC1E for ; Mon, 11 Jul 2011 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6BB6vqR076913 for ; Mon, 11 Jul 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6BB6ugW076911 for freebsd-acpi@FreeBSD.org; Mon, 11 Jul 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jul 2011 11:06:56 GMT Message-Id: <201107111106.p6BB6ugW076911@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org 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, 11 Jul 2011 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/73823 acpi [request] acpi / power-on by timer support o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 42 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 11 16:07:51 2011 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 B01B61065672; Mon, 11 Jul 2011 16:07:51 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C39C8FC13; Mon, 11 Jul 2011 16:07:50 +0000 (UTC) Received: by vxg33 with SMTP id 33so3839838vxg.13 for ; Mon, 11 Jul 2011 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kKsWA+1RvyJSC7hfvgxS3G7wjm4M1uHmC/9IYeE1vrk=; b=cl9b7UZvzRzrU89P3U6cWo35HbSdc62r7KTARVRlDEJEaKSdCMayWCV5j3tuejNm73 m22N/edJTgpKO7fO0n8MVyqMfzecl92vJz2PEiGSYXqVuK0WdzNBjbLYI9I6K9KV3Pfs /7t0U8nvmKRiFQ22xcVoHBHXbIwdUhpk1/1Ds= MIME-Version: 1.0 Received: by 10.52.67.97 with SMTP id m1mr4482583vdt.300.1310400470378; Mon, 11 Jul 2011 09:07:50 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Mon, 11 Jul 2011 09:07:50 -0700 (PDT) In-Reply-To: <4E16F61E.80201@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> <4E16F61E.80201@FreeBSD.org> Date: Mon, 11 Jul 2011 19:07:50 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 11 Jul 2011 16:07:51 -0000 Andriy Gapon wrote: > on 06/07/2011 22:20 Vitaly Magerya said the following: >> --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 >> +++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000 >> @@ -1194,7 +1194,7 @@ >> if (strlen(state) < 2 || toupper(state[0]) != 'C') >> return (EINVAL); >> val = (int) strtol(state + 1, NULL, 10) - 1; >> - if (val < 0 || val > cpu_cx_count - 1) >> + if (val < 0) >> return (EINVAL); >> cpu_cx_lowest = val; > > This change is a little bit more intrusive than I would like. > There are some things about cpu_cx_lowest handling in the code that make me a bit > unsure if this change is completely safe. Can you elaborate? From my reading, the only place cpu_cx_lowest is used is in acpi_cpu_notify, where sc->cpu_cx_lowest is optionally increased to min(cpu_cx_lowest, sc->cpu_cx_count - 1), which should be safe in any situation. Also note that we currently do not update cpu_cx_lowest immediately when the number of available states changes (only devd+power_profile does that). For example, if I kill devd and plug the power cord off, cpu_cx_lowest remains at C3, even though only C2 is reported. This is why the above patch shouldn't introduce situations we don't already have. > I suspect that there could be problems > on systems where number Cx states becomes smaller after some events (e.g. AC connection). I have such a system; if there are situations you'd like me to test, I can do so (so far it looks good). > I would prefer other developers to also comment on this. > Maybe it's worth while opening a PR for this proposed change. > >> You can even simplify power_profile with this change: >> >> --- power_profile.orig 2011-07-06 18:39:27.000000000 +0000 >> +++ power_profile 2011-07-06 18:40:20.000000000 +0000 >> @@ -81,8 +81,7 @@ >> # Set the various sysctls based on the profile's values. >> node="hw.acpi.cpu.cx_lowest" >> highest_value="C1" >> -lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ >> - awk '{ print "C" split($0, a) }' -) 2> /dev/null`" >> +lowest_value="C99" >> eval value=\$${profile}_cx_lowest >> sysctl_set > > C99 looks too scary (and too familiar) :-) > I think that C6 would be sufficient here. I expect people to get confused over such change to power_profile, so I'm not sure if I like it myself. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 11 16:08:07 2011 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 6D1EF1065674; Mon, 11 Jul 2011 16:08:07 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADF88FC1D; Mon, 11 Jul 2011 16:08:06 +0000 (UTC) Received: by vws18 with SMTP id 18so3869405vws.13 for ; Mon, 11 Jul 2011 09:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=8z8rWBAS5ywTp5FxJBOSU3h5mUyFz0nMnqcirTBviMg=; b=QLBI5xI/qyHDjM2wvjs/lr8onRjUYhgaX4Uyb6ihFc5LKoSdFTG1jDDJuy69uMN+Zu Ruib+/MAPlWzVDpq/ibmsJipshCrbgFVojChJuKPBVRzersrusa8sg8RyZwsODejz9RM dfhipyJ3HfvEvXfVZw0QvUeaYXLKzcke63g7I= MIME-Version: 1.0 Received: by 10.52.94.46 with SMTP id cz14mr2337072vdb.501.1310400486191; Mon, 11 Jul 2011 09:08:06 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Mon, 11 Jul 2011 09:08:06 -0700 (PDT) Date: Mon, 11 Jul 2011 19:08:06 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: (Missing) brightness controls of an Atom N455-based netbook 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, 11 Jul 2011 16:08:07 -0000 Andriy Gapon wrote: >> From what I heard this isn't a problem with FreeBSD ACPI code, it's >> a problem with Samsung firmware. AFAIK to get brightness controls >> working on Windows you need to setup Samsung software that uses >> undocument BIOS interface for it's function. >> >> Linux has what appears to be a reverse-engineered driver [1] that >> does the same. Someone (probably me) needs to port it. > > Maybe, maybe not... Can you please verify which driver Linux actually uses on > your system? Nothing but generic ACPI; samsung-laptop dirver is not used because it doesn't white-list my laptop model (and for some reason fails to attach when I load it with force=1, even though my BIOS definitely has the signatures it is looking for). At any rate, brightness controls don't work under Linux. > So I can see how this behavior can easily confuse our acpi_video driver. > I see that Linux acpi video driver has some quirks in it, but not sure if it is > able to handle this kind of issues. I would doubt that. > > Maybe you would feel adventurous enough to experiment with hacking your DSDT some > more. For a start I would just try to remove that level % 10 == 0 check. Sure. I removed those checks, but there isn't much difference. Here's a sample transcript: # sysctl hw.acpi.video hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 5 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.ecoomy: 5 hw.acpi.video.lcd0.levels: 100 5 15 24 30 45 60 80 hw.acpi.video.ext0.active: 0 hw.acpi.video.out0.active: 0 # sysctl hw.acpi.video.lcd0.brightness=45 hw.acpi.video.lcd0.brightness: 5 -> 45 # sysctl hw.acpi.video.lcd0.brightness=100 hw.acpi.video.lcd0.brightness: 45 -> 100 No brightness changes actually occur during this. From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 00:01:32 2011 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 27ED61065670 for ; Tue, 12 Jul 2011 00:01:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E33E88FC08 for ; Tue, 12 Jul 2011 00:01:31 +0000 (UTC) Received: by gxk28 with SMTP id 28so2170272gxk.13 for ; Mon, 11 Jul 2011 17:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=noTpkrHbDAMxC/wikxN5L7DMDBCtTyaqvchsep0KEU8=; b=jgO9ABhQ5ZnfVyn1rmwUlG8uqkfmuW+uNprAjArOtDDwWlkacLkDowyfU93JsFdXJj u8WR7bHh8Zez2EMjiLa0/hw9nb4SQdbtPyrpWW9xV1kgmVr+51+3DLMqpGqzKvtZKzcZ fp/EiHzutkelwwa1xshrw0/6lxKbcQXj/3y5Q= MIME-Version: 1.0 Received: by 10.151.4.20 with SMTP id g20mr4657087ybi.86.1310427283852; Mon, 11 Jul 2011 16:34:43 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Mon, 11 Jul 2011 16:34:43 -0700 (PDT) Date: Mon, 11 Jul 2011 16:34:43 -0700 Message-ID: From: Kevin Oberman To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: acpi_ibm fails to work on new laptop 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: Tue, 12 Jul 2011 00:01:32 -0000 I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm is not functional. 'sysctl dev.acpi_ibm' returns nothing. No volume control, though MUTE does work. Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably should change all "IBM references to LENOVO while I'm at it.) I'll probably give this a shot, just to see if it works. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 15:07:02 2011 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 73A27106566C for ; Tue, 12 Jul 2011 15:07:02 +0000 (UTC) (envelope-from nm.knife@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1C48FC0A for ; Tue, 12 Jul 2011 15:07:01 +0000 (UTC) Received: by iwr19 with SMTP id 19so6061850iwr.13 for ; Tue, 12 Jul 2011 08:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O+vlXQrYz4MQr4ZSlFNZdPDAXdAkhLMhD9B+eUr07Iw=; b=WC3dTAblIKzY+rPynzPLnkWL4QRs74JTKxoCf2ngp1zuhc7we/a/F9PYKBbXBCn1fv TmBT6NvnWOHeVj12H0ZPo8gf7t/Bi6SFfE4dBTkKVW1n16wooZN+/ZuSreLUmWhmNcNZ IxKgwP+EhGp+Fu69zFF0zn9r2hAUssoBSOm94= MIME-Version: 1.0 Received: by 10.231.112.150 with SMTP id w22mr11001ibp.61.1310481502629; Tue, 12 Jul 2011 07:38:22 -0700 (PDT) Received: by 10.231.166.6 with HTTP; Tue, 12 Jul 2011 07:38:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2011 07:38:22 -0700 Message-ID: From: =?windows-1251?B?y/7h7uzo8CDD8Ojj7vDu4g==?= To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_ibm fails to work on new laptop 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: Tue, 12 Jul 2011 15:07:02 -0000 Are you runnig 32bit or 64bit? 32bit sleep with SMP is broken AFAIK. You can try to disable SMP and see if it sleeps in case you are using 32bit. Otherwise, suspend/resume is still iffy in FreeBSD. 2011/7/11 Kevin Oberman > I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm > is not functional. 'sysctl dev.acpi_ibm' > returns nothing. No volume control, though MUTE does work. > > Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably > should change all "IBM references to LENOVO while I'm at it.) > I'll probably give this a shot, just to see if it works. > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6558@gmail.com > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > -- Lyubomir Grigorov (bgalakazam) From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 15:20:12 2011 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 3411E1065670 for ; Tue, 12 Jul 2011 15:20:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7406E8FC16 for ; Tue, 12 Jul 2011 15:20:11 +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 SAA15608; Tue, 12 Jul 2011 18:20:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E1C6626.7030108@FreeBSD.org> Date: Tue, 12 Jul 2011 18:20:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> <4E16F61E.80201@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Tue, 12 Jul 2011 15:20:12 -0000 on 11/07/2011 19:07 Vitaly Magerya said the following: > Andriy Gapon wrote: >> on 06/07/2011 22:20 Vitaly Magerya said the following: >>> --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 >>> +++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000 >>> @@ -1194,7 +1194,7 @@ >>> if (strlen(state) < 2 || toupper(state[0]) != 'C') >>> return (EINVAL); >>> val = (int) strtol(state + 1, NULL, 10) - 1; >>> - if (val < 0 || val > cpu_cx_count - 1) >>> + if (val < 0) >>> return (EINVAL); >>> cpu_cx_lowest = val; >> >> This change is a little bit more intrusive than I would like. >> There are some things about cpu_cx_lowest handling in the code that make me a bit >> unsure if this change is completely safe. > > Can you elaborate? From my reading, the only place cpu_cx_lowest > is used is in acpi_cpu_notify, where sc->cpu_cx_lowest is optionally > increased to min(cpu_cx_lowest, sc->cpu_cx_count - 1), which should > be safe in any situation. This is exactly the place that I am concerned about. Probably my mind is clouded but I can not understand why acpi_cpu_set_cx_lowest() call is under the condition: if (sc->cpu_cx_lowest < cpu_cx_lowest) acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); If you or someone else can explain to me why that condition is there... > Also note that we currently do not update cpu_cx_lowest immediately > when the number of available states changes (only devd+power_profile > does that). For example, if I kill devd and plug the power cord > off, cpu_cx_lowest remains at C3, even though only C2 is reported. > This is why the above patch shouldn't introduce situations we don't > already have. Yes, quite a good point. Although I am not sure yet if what you describe is not a bug that should be fixed. >> I suspect that there could be problems >> on systems where number Cx states becomes smaller after some events (e.g. AC connection). > > I have such a system; if there are situations you'd like me to test, > I can do so (so far it looks good). I am not exactly sure what to look for... Perhaps something like this (if your system would allow it): - place the system in a state where at least C3 is supported - set global cx_lowest to C3 - set per-CPU cx_lowest for one CPU to C2 - place a system in a state where only C1 is supported This testcase is only tangentially related to your proposed change. It's more about that code that I don't understand. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 15:22:00 2011 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 732DB106564A for ; Tue, 12 Jul 2011 15:22:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C0DE98FC12 for ; Tue, 12 Jul 2011 15:21:59 +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 SAA15624; Tue, 12 Jul 2011 18:21:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E1C6694.6050706@FreeBSD.org> Date: Tue, 12 Jul 2011 18:21:56 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) brightness controls of an Atom N455-based netbook 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: Tue, 12 Jul 2011 15:22:00 -0000 on 11/07/2011 19:08 Vitaly Magerya said the following: > Andriy Gapon wrote: >>> From what I heard this isn't a problem with FreeBSD ACPI code, it's >>> a problem with Samsung firmware. AFAIK to get brightness controls >>> working on Windows you need to setup Samsung software that uses >>> undocument BIOS interface for it's function. >>> >>> Linux has what appears to be a reverse-engineered driver [1] that >>> does the same. Someone (probably me) needs to port it. >> >> Maybe, maybe not... Can you please verify which driver Linux actually uses on >> your system? > > Nothing but generic ACPI; samsung-laptop dirver is not used because > it doesn't white-list my laptop model (and for some reason fails > to attach when I load it with force=1, even though my BIOS definitely > has the signatures it is looking for). > > At any rate, brightness controls don't work under Linux. I officially give up on this case then :-) Maybe you'd want to report this problem to Linux folks too. If they come up with a fix we may borrow it from them. >> So I can see how this behavior can easily confuse our acpi_video driver. >> I see that Linux acpi video driver has some quirks in it, but not sure if it is >> able to handle this kind of issues. I would doubt that. >> >> Maybe you would feel adventurous enough to experiment with hacking your DSDT some >> more. For a start I would just try to remove that level % 10 == 0 check. > > Sure. I removed those checks, but there isn't much difference. > Here's a sample transcript: > > # sysctl hw.acpi.video > hw.acpi.video.crt0.active: 0 > hw.acpi.video.lcd0.active: 0 > hw.acpi.video.lcd0.brightness: 5 > hw.acpi.video.lcd0.fullpower: 100 > hw.acpi.video.lcd0.ecoomy: 5 > hw.acpi.video.lcd0.levels: 100 5 15 24 30 45 60 80 > hw.acpi.video.ext0.active: 0 > hw.acpi.video.out0.active: 0 > # sysctl hw.acpi.video.lcd0.brightness=45 > hw.acpi.video.lcd0.brightness: 5 -> 45 > # sysctl hw.acpi.video.lcd0.brightness=100 > hw.acpi.video.lcd0.brightness: 45 -> 100 > > No brightness changes actually occur during this. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 20:34:43 2011 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 17A7B1065670; Tue, 12 Jul 2011 20:34:43 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AEA78FC0C; Tue, 12 Jul 2011 20:34:42 +0000 (UTC) Received: by vxg33 with SMTP id 33so5165825vxg.13 for ; Tue, 12 Jul 2011 13:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y/QwccWgAL+hqmaRaqdM5a0Nd9W7cmRd8aExtFgHpsQ=; b=FtjgIU0m6CcifR64ejeb7PxzxA8mipSfJ83WnlLYbwSgrDb/vvPNIbcqIWy2XxRFPp qJANcLPjuZ485B85Mk6mm22OKpzfz/zuIXvMVw1RyRqRAotp99dGUadgxA2ZEE6ZaLVn XIXZfITIe9bdFmp9AM9BoAbbc7dmHqzCtF0LU= MIME-Version: 1.0 Received: by 10.52.175.7 with SMTP id bw7mr471509vdc.32.1310502881374; Tue, 12 Jul 2011 13:34:41 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Tue, 12 Jul 2011 13:34:40 -0700 (PDT) In-Reply-To: <4E1C6626.7030108@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> <4E16F61E.80201@FreeBSD.org> <4E1C6626.7030108@FreeBSD.org> Date: Tue, 12 Jul 2011 23:34:40 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Tue, 12 Jul 2011 20:34:43 -0000 Andriy Gapon wrote: > on 11/07/2011 19:07 Vitaly Magerya said the following: >> Can you elaborate? From my reading, the only place cpu_cx_lowest >> is used is in acpi_cpu_notify, where sc->cpu_cx_lowest is optionally >> increased to min(cpu_cx_lowest, sc->cpu_cx_count - 1), which should >> be safe in any situation. > > This is exactly the place that I am concerned about. > Probably my mind is clouded but I can not understand why > acpi_cpu_set_cx_lowest() > call is under the condition: > if (sc->cpu_cx_lowest < cpu_cx_lowest) > acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); > > If you or someone else can explain to me why that condition is there... Now that I think about it, yes it does look like a bug. Here's how to trigger it: 1. Kill devd. 2. Make sure you've got C3, set hw.acpi.cpu.cx_lowest to C3. 3. Plug the power cord in (only C2 is now reported). 4. Look at dev.cpu.N.cx_lowest: it's still C3, even though dev.cpu.N.cx_supported only has C1 and C2. This happens because normally sc->cpu_cx_lowest == cpu_cx_lowest, so the update isn't executed, and sc->cpu_cx_lowest remains as before. In short, that update should probably be executed unconditionally. From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 12 21:04:12 2011 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 BB92D1065670; Tue, 12 Jul 2011 21:04:12 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 35E3F8FC12; Tue, 12 Jul 2011 21:04:11 +0000 (UTC) Received: by vws18 with SMTP id 18so5212241vws.13 for ; Tue, 12 Jul 2011 14:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3gzLLHSIo+ARlQjJvn5TmHxhUO5xS8PJSZWIPHcRHk=; b=vBq8W8IilIygaMgKI9wQ+PQe86SwPAFSpxKY4CFicxYD7v3X23eynoVrXzRuL8KaW6 i7+DCIpU6aLURlXPcTgKdY4Jq1Qhe2Rf53GDm6dbHqY98mAj0ket70DnMrXCjn1RnZK8 4wWVZ+R5p5s2NGSFh1ona9fs+LlsqIBvHDL0U= MIME-Version: 1.0 Received: by 10.52.74.34 with SMTP id q2mr479356vdv.233.1310504651224; Tue, 12 Jul 2011 14:04:11 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Tue, 12 Jul 2011 14:04:11 -0700 (PDT) In-Reply-To: References: <4E0A41C8.3000904@FreeBSD.org> <201106301655.19258.jkim@FreeBSD.org> Date: Wed, 13 Jul 2011 00:04:11 +0300 Message-ID: From: Vitaly Magerya To: Jung-uk Kim Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Tue, 12 Jul 2011 21:04:12 -0000 Vitaly Magerya wrote: > Jung-uk Kim m@freebsd.org> wrote: >> I have written a very rough patch and it is available from here: >> >> http://people.freebsd.org/m/acpi_cst.diff >> >> It compiles but wasn't tested at all, i.e., I have no hardware. >> Please be careful. > > Cool. I'll try it. Sorry for the delay (I had to install CURRENT first). When I boot a kernel with that patch, I get this panic: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc04cd782 stack pointer = 0x28:0xc3bddc3c frame pointer = 0x28:0xc3bddc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) [ thread pid 11 tid 100003 ] Stopped at acpi_cpi_idle+0x1c2: monitor Here's the backtrace: Tracing pid 11 tid 100003 td 0xc3d7f8a0 acpi_cpu_idle(1d,c3bddca4,c0992e99,0,1d,...) at acpi_cpu_idle+0x1c2 cpu_idle_acpi(0,1d,0,c3d7f8a0,c3bddcec,...) at cpu_idle_acpi+0x2f cpu_idle(0,c3bddcc8,c0a27d18,a03,c3d7f8a0,...) at cpu_idle+0x89 sed_idletd(0,c3bddd28,ff7ff3ff,c3d7d840,0,...) at sched_idletd+0x249 fork_exit(c0721060,0,c3bddd28) at fork_exit+0x97 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3bddd60, ebp = 0 --- (Yes, I typed all that manually). My kernel is GENERIC without WITNESS, INVARIANTS and a whole lot of drivers my system doesn't need (I can show the file on request). From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 13 02:45:25 2011 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 3437C106566B; Wed, 13 Jul 2011 02:45:25 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id C529D8FC16; Wed, 13 Jul 2011 02:45:24 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 6D1CD133AC; Wed, 13 Jul 2011 11:45:23 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6kbWBpv-kDj; Wed, 13 Jul 2011 11:45:17 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Wed, 13 Jul 2011 11:45:17 +0900 (JST) Date: Wed, 13 Jul 2011 11:45:21 +0900 From: Taku YAMAMOTO To: Vitaly Magerya Message-Id: <20110713114521.9f684b01.taku@tackymt.homeip.net> In-Reply-To: References: <4E0A41C8.3000904@FreeBSD.org> <201106301655.19258.jkim@FreeBSD.org> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Wed, 13 Jul 2011 02:45:25 -0000 Ah, the line in the acpi_cpu_mwait function should be read as: cpu_monitor(state, 0, 0); Vitaly, could you test the jkim's patch again with the above line modified? Jung-uk, the MONITOR insn seems to result in GPF if its extensions is anything but zero. # I admit it's very confusing that the semantics of extensions to # MONITOR and MWAIT are different from each other... On Wed, 13 Jul 2011 00:04:11 +0300 Vitaly Magerya wrote: > Vitaly Magerya wrote: > > Jung-uk Kim m@freebsd.org> wrote: > >> I have written a very rough patch and it is available from here: > >> > >> http://people.freebsd.org/m/acpi_cst.diff > >> > >> It compiles but wasn't tested at all, i.e., I have no hardware. > >> Please be careful. > > > > Cool. I'll try it. > > Sorry for the delay (I had to install CURRENT first). > > When I boot a kernel with that patch, I get this panic: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc04cd782 > stack pointer = 0x28:0xc3bddc3c > frame pointer = 0x28:0xc3bddc80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 11 (idle: cpu0) > [ thread pid 11 tid 100003 ] > Stopped at acpi_cpi_idle+0x1c2: monitor > > Here's the backtrace: > > Tracing pid 11 tid 100003 td 0xc3d7f8a0 > acpi_cpu_idle(1d,c3bddca4,c0992e99,0,1d,...) at acpi_cpu_idle+0x1c2 > cpu_idle_acpi(0,1d,0,c3d7f8a0,c3bddcec,...) at cpu_idle_acpi+0x2f > cpu_idle(0,c3bddcc8,c0a27d18,a03,c3d7f8a0,...) at cpu_idle+0x89 > sed_idletd(0,c3bddd28,ff7ff3ff,c3d7d840,0,...) at sched_idletd+0x249 > fork_exit(c0721060,0,c3bddd28) at fork_exit+0x97 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc3bddd60, ebp = 0 --- > > (Yes, I typed all that manually). > > My kernel is GENERIC without WITNESS, INVARIANTS and a whole lot > of drivers my system doesn't need (I can show the file on request). > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- -|-__ 山本　拓 / YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 13 14:32:20 2011 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 D0E9C106564A; Wed, 13 Jul 2011 14:32:20 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57B1E8FC14; Wed, 13 Jul 2011 14:32:20 +0000 (UTC) Received: by vws18 with SMTP id 18so5855307vws.13 for ; Wed, 13 Jul 2011 07:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tnx8DpnvFWjzn3RSWavu6750e0xDvL2L59+KhvA6tlY=; b=UeAISrXGvL2to5U2neV2YRVc4JfCn6iUMYlurz4+EyBbp3WyV+jGF3hNT2NiSLgSPZ A3qzNvKiiDKjT2cQNH/+nbGj4GBh2rfrAUvutTvZQoPRutNfP6Bh9hAZlJzZkIBvbM3q 5ArhZiOYHIEAIPkmvQtIh2/D18/eT8SgvcBlE= MIME-Version: 1.0 Received: by 10.52.73.34 with SMTP id i2mr1244577vdv.166.1310567539692; Wed, 13 Jul 2011 07:32:19 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Wed, 13 Jul 2011 07:32:19 -0700 (PDT) In-Reply-To: <20110713114521.9f684b01.taku@tackymt.homeip.net> References: <4E0A41C8.3000904@FreeBSD.org> <201106301655.19258.jkim@FreeBSD.org> <20110713114521.9f684b01.taku@tackymt.homeip.net> Date: Wed, 13 Jul 2011 17:32:19 +0300 Message-ID: From: Vitaly Magerya To: Taku YAMAMOTO Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Wed, 13 Jul 2011 14:32:20 -0000 Taku YAMAMOTO wrote: > Ah, the line in the acpi_cpu_mwait function should be read as: > > cpu_monitor(state, 0, 0); > > Vitaly, could you test the jkim's patch again with the above line modified? Sure. With the above change it hangs during the boot. Here are the last two lines before the hang with verbose boot: acpi_acad0: acline initialization start acpi_battery0: battery initialization start From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 13 16:03:00 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 522851065670; Wed, 13 Jul 2011 16:03:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Vitaly Magerya Date: Wed, 13 Jul 2011 12:02:50 -0400 User-Agent: KMail/1.6.2 References: <20110713114521.9f684b01.taku@tackymt.homeip.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107131202.53344.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Wed, 13 Jul 2011 16:03:00 -0000 On Wednesday 13 July 2011 10:32 am, Vitaly Magerya wrote: > Taku YAMAMOTO wrote: > > Ah, the line in the acpi_cpu_mwait function should be read as: > > > > cpu_monitor(state, 0, 0); > > > > Vitaly, could you test the jkim's patch again with the above line > > modified? I fixed that bug in the later patches, e.g., http://people.freebsd.org/~jkim/acpi_cx_native.diff However, it doesn't work yet. Please see below. > Sure. With the above change it hangs during the boot. > > Here are the last two lines before the hang with verbose boot: > > acpi_acad0: acline initialization start > acpi_battery0: battery initialization start It is a known problem and the above patch hangs, too. :-( Actually, I abandoned the patches and I am thinking about rewriting it from scratch, e.g., refactoring MI/MD support code (dev/acpica/acpi_cpu.c -> machine/machdep.c & acpica/acpi_machdep.c). Unfortunately, I don't have much time nor hardware to test, so it won't happen any time soon. Sorry. If anyone wants to pick it up from here, please feel free. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 13 17:45:47 2011 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 ECAE31065675 for ; Wed, 13 Jul 2011 17:45:47 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 51AAB8FC0C for ; Wed, 13 Jul 2011 17:45:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p6DHUXMr018820; Thu, 14 Jul 2011 03:30:33 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 14 Jul 2011 03:30:32 +1000 (EST) From: Ian Smith To: Kevin Oberman In-Reply-To: Message-ID: <20110714024956.J5838@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_ibm fails to work on new laptop 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: Wed, 13 Jul 2011 17:45:48 -0000 On Mon, 11 Jul 2011 16:34:43 -0700, Kevin Oberman wrote: > I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm > is not functional. 'sysctl dev.acpi_ibm' > returns nothing. No volume control, though MUTE does work. Is the module actually loading? If so, verbose dmesg shpuld say like Preloaded elf module "/boot/kernel/acpi_ibm.ko" at 0xc103b2e0 and presumably whinge if it failed to load? > Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably > should change all "IBM references to LENOVO while I'm at it.) > I'll probably give this a shot, just to see if it works. Change where? No OEMID in /sys/dev/acpi_support/acpi_ibm.c at 8.2-R. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 14 15:22:30 2011 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 AE8471065677 for ; Thu, 14 Jul 2011 15:22:30 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 704B08FC15 for ; Thu, 14 Jul 2011 15:22:30 +0000 (UTC) Received: by yic13 with SMTP id 13so185460yic.13 for ; Thu, 14 Jul 2011 08:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zJHy/D9WpqKymibqZEvcE+60LXvxcwISCxpl4WCKT9Q=; b=pfAcU68k4sQ0LEysy0I2i2Gla5Brj8LzEu3M2Eoi7coGhgxx18p+pYFmhEWHHycI1m uX3ofJfOMunUPmeGlPWDRlQ0DLwRuU1Icd3D0s2jow6B+vlKtApWKQ9jyREzXi0bXLrr 7qKv8apma6/cQZR+k4COVZD00M4ndBbQ7Aw1M= MIME-Version: 1.0 Received: by 10.151.109.8 with SMTP id l8mr2684708ybm.27.1310656949676; Thu, 14 Jul 2011 08:22:29 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Thu, 14 Jul 2011 08:22:29 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Thu, 14 Jul 2011 08:22:29 -0700 (PDT) Date: Thu, 14 Jul 2011 08:22:29 -0700 Message-ID: From: Kevin Oberman To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_ibm fails to work on new laptop 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: Thu, 14 Jul 2011 15:22:30 -0000 On Jul 13, 2011 10:30 AM, "Ian Smith" wrote: > > On Mon, 11 Jul 2011 16:34:43 -0700, Kevin Oberman wrote: > > > I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm > > is not functional. 'sysctl dev.acpi_ibm' > > returns nothing. No volume control, though MUTE does work. > > Is the module actually loading? If so, verbose dmesg shpuld say like > Preloaded elf module "/boot/kernel/acpi_ibm.ko" at 0xc103b2e0 > and presumably whinge if it failed to load? > > > Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably > > should change all "IBM references to LENOVO while I'm at it.) > > I'll probably give this a shot, just to see if it works. > > Change where? No OEMID in /sys/dev/acpi_support/acpi_ibm.c at 8.2-R. > > cheers, Ian Yes, it loads fine. I see the load message at boot and kldstat shows it. I dumped the asl and it has the OEMID set to LENOVO, where.my T43 has IBM. At the start of the code is: #define _COMPONENT ACPI_OEM ACPI_MODULE_NAME("IBM") I'm guessing that the OEMID and the ACPI_MODULE_NAME need to match. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 14 15:31:24 2011 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 567061065678 for ; Thu, 14 Jul 2011 15:31:24 +0000 (UTC) (envelope-from edv@agile.bc.ca) Received: from defout.telus.net (defout.telus.net [204.209.205.30]) by mx1.freebsd.org (Postfix) with ESMTP id B6AE28FC17 for ; Thu, 14 Jul 2011 15:31:23 +0000 (UTC) Received: from edmwcm02 ([204.209.205.30]) by priv-edmwes04.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110714153117.HVJS24872.priv-edmwes04.telusplanet.net@edmwcm02> for ; Thu, 14 Jul 2011 09:31:17 -0600 Received: from [192.168.0.253] ([75.155.141.59]) by edmwcm02 with bizsmtp id 7rXH1h00d1H5dnv01rXHPE; Thu, 14 Jul 2011 09:31:17 -0600 X-Authority-Analysis: v=1.1 cv=PaS+rgWywBuMo+rlDu2yD6cS+QI8Ou1WsTUJ6HmG/7s= c=1 sm=2 a=00GrbmtOa5AA:10 a=lp1F1aYoXqwA:10 a=8nJEP1OIZ-IA:10 a=wFaEK3txAAAA:8 a=tRTBw__SEBnbI5m3VfYA:9 a=wPNLvfGTeEIA:10 a=5Ut32mfbI-AA:10 X-Telus-Outbound-IP: 75.155.141.59 Message-ID: <4E1F0BC1.4030802@agile.bc.ca> Date: Thu, 14 Jul 2011 08:31:13 -0700 From: Ed VanderPloeg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Andriy Gapon References: <4E0A50AA.5000003@agile.bc.ca> <4E0AF27B.3030600@FreeBSD.org> <4E0B6873.6010901@agile.bc.ca> <4E0B80BE.6080605@FreeBSD.org> <4E0CA533.5030104@agile.bc.ca> <4E0CE39C.5050307@FreeBSD.org> <4E0D4A15.6000904@agile.bc.ca> <4E0D5EA0.1020704@FreeBSD.org> <4E0E7F91.2050408@agile.bc.ca> <4E117FE8.9030703@FreeBSD.org> In-Reply-To: <4E117FE8.9030703@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Atom N270 - ACPI Error: [RTMP] Namespace lookup failure 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: Thu, 14 Jul 2011 15:31:24 -0000 Could the system overheat, or get incorrectly shut down when acpi fails to get the current temperature? What is the best way to work around this problem? Setting a very high polling rate or disabling it inside loader.conf: debug.acpi.disable="thermal" In 2008 Kevin Foo thought it might not be safe to disable it: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2008-01/msg00791.html Or do I need to boot with ACPI disabled until a BIOS fix is available? Ed On 2011-07-04 1:55 AM, Andriy Gapon wrote: > on 02/07/2011 05:16 Ed VanderPloeg said the following: >> >> # egrep '(^| )est' dmesg.8-release >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 60f0c270600060f >> device_attach: est0 attach returned 6 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 60f0c270600060f >> device_attach: est1 attach returned 6 >> >> # egrep '(^| )est' dmesg.8-stable >> est0: on cpu0 >> est1: on cpu1 > > So this was improved. Thanks! > From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 15 08:48:21 2011 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 62326106566B; Fri, 15 Jul 2011 08:48:21 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (unknown [IPv6:2001:3e0:577:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7E98FC16; Fri, 15 Jul 2011 08:48:20 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 7EDEF133AC; Fri, 15 Jul 2011 17:48:19 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost ([127.0.0.1]) by basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRkT9yS8pkhN; Fri, 15 Jul 2011 17:48:13 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:3e0:577:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTP; Fri, 15 Jul 2011 17:48:12 +0900 (JST) Date: Fri, 15 Jul 2011 17:48:17 +0900 From: Taku YAMAMOTO To: Jung-uk Kim Message-Id: <20110715174817.9b933756.taku@tackymt.homeip.net> In-Reply-To: <201107131202.53344.jkim@FreeBSD.org> References: <20110713114521.9f684b01.taku@tackymt.homeip.net> <201107131202.53344.jkim@FreeBSD.org> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__15_Jul_2011_17_48_17_+0900_WC/_1oDFZjEbU.lx" Cc: freebsd-acpi@freebsd.org, Vitaly Magerya , Gapon , Andriy Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Fri, 15 Jul 2011 08:48:21 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__15_Jul_2011_17_48_17_+0900_WC/_1oDFZjEbU.lx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 13 Jul 2011 12:02:50 -0400 Jung-uk Kim wrote: > I fixed that bug in the later patches, e.g., > > http://people.freebsd.org/~jkim/acpi_cx_native.diff I'm afraid spinning on *state == STATE_MWAIT doesn't work well for hardware- originated interrupts. Other than that, basically I like yours better than my dirty one. # I'm attaching my dirty hack for the reference. > However, it doesn't work yet. Please see below. > > On Wednesday 13 July 2011 10:32 am, Vitaly Magerya wrote: > > Sure. With the above change it hangs during the boot. > > > > Here are the last two lines before the hang with verbose boot: > > > > acpi_acad0: acline initialization start > > acpi_battery0: battery initialization start > > It is a known problem and the above patch hangs, too. :-( It's quite strange... Maybe we have to tell the BIOS that we are going to utilize _CST via SMI. In fact, the major difference between mine and jkim's is that in mine I took the following snippet (which we can find in acpi_cpu_startup_cx function, living in sys/dev/acpica/acpi_cpu.c) out of #ifdef notyet. -#ifdef notyet /* Signal platform that we can handle _CST notification. */ if (!cpu_cx_generic && cpu_cst_cnt != 0) { ACPI_LOCK(acpi); AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); ACPI_UNLOCK(acpi); } -#endif Vitaly, could you remove the above-mentioned #ifdef-#endif pair (to activate the code inbetween) and test jkim's patch again? > Actually, I abandoned the patches and I am thinking about rewriting it > from scratch, e.g., refactoring MI/MD support code > (dev/acpica/acpi_cpu.c -> machine/machdep.c & acpica/acpi_machdep.c). > Unfortunately, I don't have much time nor hardware to test, so it > won't happen any time soon. Sorry. > > If anyone wants to pick it up from here, please feel free. > > Jung-uk Kim I have a laptop which carries Core 2 Duo which can MWAIT_C3 (and actually it works with my hack). Though I don't rebuild the kernel often these days, I will happily test your new patches next time. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Fri__15_Jul_2011_17_48_17_+0900_WC/_1oDFZjEbU.lx Content-Type: text/plain; name="acpi_cx_native-tackymt-20110406.patch" Content-Disposition: attachment; filename="acpi_cx_native-tackymt-20110406.patch" Content-Transfer-Encoding: 7bit diff -rup --exclude='*~' --exclude='*.patch' /sys/dev/acpica/acpi_cpu.c native_cx/dev/acpica/acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c.orig 2010-11-13 02:10:12.000000000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-11-30 16:45:50.087748111 +0900 @@ -65,6 +65,12 @@ struct acpi_cx { uint32_t trans_lat; /* Transition latency (usec). */ uint32_t power; /* Power consumed (mW). */ int res_type; /* Resource type for p_lvlx. */ +#ifdef ACPI_USE_NATIVE_CX +#define pseudo_RES_FFIXEDHW 0 /* FFixedHW pseudo resource */ + uint16_t code; /* Encoded as BitWidth/BitOffset */ + uint8_t arg1; /* Encoded as AccessWidth */ + uint64_t arg0; /* Encoded as Address */ +#endif /* ACPI_USE_NATIVE_CX */ }; #define MAX_CX_STATES 8 @@ -336,6 +342,9 @@ acpi_cpu_attach(device_t dev) * SMP control where each CPU can have different settings. */ sc->cpu_features = ACPI_CAP_SMP_SAME | ACPI_CAP_SMP_SAME_C3; +#ifdef ACPI_USE_NATIVE_CX /* XXX */ + sc->cpu_features |= ACPI_CAP_SMP_C1_NATIVE | ACPI_CAP_SMP_C3_NATIVE; +#endif if (devclass_get_drivers(acpi_cpu_devclass, &drivers, &drv_count) == 0) { for (i = 0; i < drv_count; i++) { if (ACPI_GET_FEATURES(drivers[i], &features) == 0) @@ -695,6 +704,7 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s /* Validate the state to see if we should use it. */ switch (cx_ptr->type) { case ACPI_STATE_C1: +#ifndef ACPI_USE_NATIVE_CX if (sc->cpu_cx_states[0].type == ACPI_STATE_C0) { /* This is the first C1 state. Use the reserved slot. */ sc->cpu_cx_states[0] = *cx_ptr; @@ -704,6 +714,7 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s sc->cpu_cx_count++; } continue; +#endif case ACPI_STATE_C2: sc->cpu_non_c3 = i; break; @@ -726,6 +737,27 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s } #endif +#ifdef ACPI_USE_NATIVE_CX + /* Check for FFixedHW first. */ + if (acpi_PkgGasFFH(pkg, 0, &cx_ptr->code, &cx_ptr->arg0, &cx_ptr->arg1) == 0) { + /* We do not increment cpu_rid, because FixedHW isn't a resource. */ + cx_ptr->res_type = pseudo_RES_FFIXEDHW; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: Got C%d - %d latency\n", + device_get_unit(sc->cpu_dev), cx_ptr->type, + cx_ptr->trans_lat)); + if (cx_ptr->type == ACPI_STATE_C1 && + sc->cpu_cx_states[0].type == ACPI_STATE_C0) { + /* This is the first C1 state. Use the reserved slot. */ + sc->cpu_cx_states[0] = *cx_ptr; + } else { + cx_ptr++; + sc->cpu_cx_count++; + } + continue; + } +#endif + /* Allocate the control register for C2 or C3. */ acpi_PkgGas(sc->cpu_dev, pkg, 0, &cx_ptr->res_type, &sc->cpu_rid, &cx_ptr->p_lvlx, RF_SHAREABLE); @@ -746,6 +778,10 @@ acpi_cpu_cx_cst(struct acpi_cpu_softc *s if (cx_ptr->type == ACPI_STATE_C0) { cx_ptr->type = ACPI_STATE_C1; cx_ptr->trans_lat = 0; +#ifdef ACPI_USE_NATIVE_CX + cx_ptr->res_type = pseudo_RES_FFIXEDHW; + cx_ptr->code = 0; +#endif } return (0); @@ -791,6 +827,8 @@ acpi_cpu_startup(void *arg) if (sc->cpu_cx_count < cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; } + if (cpu_cx_count <= 1) + return; } else { /* * We are using _CST mode, remove C3 state if necessary. @@ -871,14 +909,12 @@ acpi_cpu_startup_cx(struct acpi_cpu_soft (void *)sc, 0, acpi_cpu_usage_sysctl, "A", "percent usage for each Cx state"); -#ifdef notyet /* Signal platform that we can handle _CST notification. */ if (!cpu_cx_generic && cpu_cst_cnt != 0) { ACPI_LOCK(acpi); AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); ACPI_UNLOCK(acpi); } -#endif } /* @@ -952,7 +988,11 @@ acpi_cpu_idle() * is an ISR. Assume we slept no more then half of quantum, unless * we are called inside critical section, delaying context switch. */ - if (cx_next->type == ACPI_STATE_C1) { + if (cx_next->type == ACPI_STATE_C1 +#ifdef ACPI_USE_NATIVE_CX + && cx_next->code == 0 +#endif + ) { AcpiHwRead(&start_time, &AcpiGbl_FADT.XPmTimerBlock); acpi_cpu_c1(); AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); @@ -982,6 +1022,11 @@ acpi_cpu_idle() * is the only reliable time source. */ AcpiHwRead(&start_time, &AcpiGbl_FADT.XPmTimerBlock); +#ifdef ACPI_USE_NATIVE_CX + if (cx_next->res_type == pseudo_RES_FFIXEDHW) + acpi_cpu_cx_native(cx_next->code, cx_next->arg0, cx_next->arg1); + else { +#endif CPU_GET_REG(cx_next->p_lvlx, 1); /* @@ -991,6 +1036,9 @@ acpi_cpu_idle() * margin that we are certain to have a correct value. */ AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); +#ifdef ACPI_USE_NATIVE_CX + } +#endif AcpiHwRead(&end_time, &AcpiGbl_FADT.XPmTimerBlock); /* Enable bus master arbitration and disable bus master wakeup. */ @@ -999,11 +1047,15 @@ acpi_cpu_idle() AcpiWriteBitRegister(ACPI_BITREG_ARB_DISABLE, 0); AcpiWriteBitRegister(ACPI_BITREG_BUS_MASTER_RLD, 0); } - ACPI_ENABLE_IRQS(); /* Find the actual time asleep in microseconds. */ - end_time = acpi_TimerDelta(end_time, start_time); - sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; + end_time = PM_USEC(acpi_TimerDelta(end_time, start_time)); +#ifdef notyet + if (cx_may_nonatomic && curthread->td_critnest == 0) + end_time = min(end_time, 500000 / hz); +#endif + sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + end_time) / 4; + ACPI_ENABLE_IRQS(); } /* diff -rup --exclude='*~' --exclude='*.patch' /sys/dev/acpica/acpi_package.c native_cx/dev/acpica/acpi_package.c --- sys/dev/acpica/acpi_package.c 2010-01-22 06:14:28.000000000 +0900 +++ sys/dev/acpica/acpi_package.c 2010-10-11 06:28:24.777637413 +0900 @@ -103,11 +103,9 @@ acpi_PkgStr(ACPI_OBJECT *res, int idx, v return (0); } -int -acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, - struct resource **dst, u_int flags) +static int +acpi_get_PkgGas(ACPI_OBJECT *res, int idx, ACPI_GENERIC_ADDRESS *gas) { - ACPI_GENERIC_ADDRESS gas; ACPI_OBJECT *obj; obj = &res->Package.Elements[idx]; @@ -115,11 +113,48 @@ acpi_PkgGas(device_t dev, ACPI_OBJECT *r obj->Buffer.Length < sizeof(ACPI_GENERIC_ADDRESS) + 3) return (EINVAL); - memcpy(&gas, obj->Buffer.Pointer + 3, sizeof(gas)); + memcpy(gas, obj->Buffer.Pointer + 3, sizeof(*gas)); + return (0); +} + +int +acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, + struct resource **dst, u_int flags) +{ + ACPI_GENERIC_ADDRESS gas; + int r; + r = acpi_get_PkgGas(res, idx, &gas); + if (r != 0) + return (r); return (acpi_bus_alloc_gas(dev, type, rid, &gas, dst, flags)); } +int +acpi_PkgGasFFH(ACPI_OBJECT *res, int idx, uint16_t *code, UINT64 *arg0, + uint8_t *arg1) +{ + ACPI_GENERIC_ADDRESS gas; + int r; + uint8_t vendorcode, classcode; + + r = acpi_get_PkgGas(res, idx, &gas); + if (r != 0) + return (r); + + if (gas.SpaceId != ACPI_ADR_SPACE_FIXED_HARDWARE) + return (EOPNOTSUPP); + + /* Extract encoded values. */ + vendorcode = gas.BitWidth; + classcode = gas.BitOffset; + *code = vendorcode | ((uint16_t)classcode << 8); + *arg1 = gas.AccessWidth; + *arg0 = gas.Address; + + return (0); +} + ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj) { diff -rup --exclude='*~' --exclude='*.patch' /sys/dev/acpica/acpivar.h native_cx/dev/acpica/acpivar.h --- sys/dev/acpica/acpivar.h.orig 2011-02-26 03:29:57.000000000 +0900 +++ sys/dev/acpica/acpivar.h 2011-03-09 14:35:39.477877295 +0900 @@ -454,6 +454,8 @@ int acpi_PkgInt32(ACPI_OBJECT *res, int int acpi_PkgStr(ACPI_OBJECT *res, int idx, void *dst, size_t size); int acpi_PkgGas(device_t dev, ACPI_OBJECT *res, int idx, int *type, int *rid, struct resource **dst, u_int flags); +int acpi_PkgGasFFH(ACPI_OBJECT *res, int idx, uint16_t *code, + UINT64 *arg0, uint8_t *arg1); ACPI_HANDLE acpi_GetReference(ACPI_HANDLE scope, ACPI_OBJECT *obj); /* diff -rup --exclude='*~' --exclude='*.patch' /sys/i386/acpica/acpi_machdep.c native_cx/i386/acpica/acpi_machdep.c --- sys/i386/acpica/acpi_machdep.c 2010-03-19 21:43:18.000000000 +0900 +++ sys/i386/acpica/acpi_machdep.c 2010-11-01 15:29:54.018653408 +0900 @@ -559,6 +559,50 @@ acpi_cpu_c1() __asm __volatile("sti; hlt"); } +extern void cpu_idle_mwait_hint(uint32_t); /* XXX */ + +/* + * code: vendor | (classcode << 8) + * vendor: ACPI_GENERIC_ADDRESS.BitWidth (8-bit). + * classcode: ACPI_GENERIC_ADDRESS.BitOffset (8-bit). + * arg0: ACPI_GENERIC_ADDRESS.Address (64-bit). + * arg1: ACPI_GENERIC_ADDRESS.AccessWidth (8-bit). + */ +void +acpi_cpu_cx_native(uint16_t code, uint64_t arg0, uint8_t arg1) +{ + switch (code) { + /* 0x##01: Intel */ + case 0x0101: + /* + * C1 I/O then HLT. + * arg0: I/O port address to inb. + * arg1: not used (supposed to be 0). + */ + __asm __volatile( + "inb %w0, %%al\n\t" + "sti; hlt" + :: "d" ((uint16_t)arg0) : "al"); + break; + + case 0x0201: + /* + * Native C state insn, a.k.a. MWAIT. + * arg0[31:0] : hint for MWAIT (through EAX). + * arg1[0] : H/W-coordinated. + * arg1[1] : Requires bus-master avoidance. (BM_CTRL) + */ + cpu_idle_mwait_hint((uint32_t)arg0); + break; + + /* More vendors? */ + + default: + /* Defaults to STI-HLT sequence. */ + __asm __volatile("sti; hlt"); + } +} + /* * Support for mapping ACPI tables during early boot. This abuses the * crashdump map because the kernel cannot allocate KVA in diff -rup --exclude='*~' --exclude='*.patch' /sys/i386/i386/machdep.c native_cx/i386/i386/machdep.c --- sys/i386/i386/machdep.c.orig 2011-04-08 05:03:12.282748503 +0900 +++ sys/i386/i386/machdep.c 2011-04-08 05:47:54.071749599 +0900 @@ -1226,6 +1226,7 @@ cpu_halt(void) void (*cpu_idle_hook)(void) = NULL; /* ACPI idle hook. */ static int cpu_ident_amdc1e = 0; /* AMD C1E supported. */ +static int cpu_ident_mwait_intr_ext = 0; static int idle_mwait = 1; /* Use MONITOR/MWAIT for short idle. */ TUNABLE_INT("machdep.idle_mwait", &idle_mwait); SYSCTL_INT(_machdep, OID_AUTO, idle_mwait, CTLFLAG_RW, &idle_mwait, @@ -1282,6 +1283,11 @@ cpu_idle_hlt(int busy) #define MWAIT_C3 0x20 #define MWAIT_C4 0x30 +/* + * MWAIT extensions. + */ +#define MWAIT_INTR 0x01 /* an INT breaks MWAIT even if it's disabled. */ + static void cpu_idle_mwait(int busy) { @@ -1297,6 +1303,25 @@ cpu_idle_mwait(int busy) *state = STATE_RUNNING; } +void cpu_idle_mwait_hint(uint32_t); /* XXX */ +void +cpu_idle_mwait_hint(uint32_t hint) +{ + int *state; + + state = (int *)PCPU_PTR(monitorbuf); + *state = STATE_MWAIT; + cpu_monitor(state, 0, 0); + if (*state == STATE_MWAIT) { + if (cpu_ident_mwait_intr_ext) + cpu_mwait(MWAIT_INTR, hint); + else { + enable_intr(); + cpu_mwait(0, hint); + } + } +} + static void cpu_idle_spin(int busy) { @@ -1341,6 +1366,21 @@ cpu_probe_amdc1e(void) } } +/* + * Check for MWAIT INTR-BREAK extension. + */ +static void +cpu_probe_mwait_ext(void) +{ + u_int regs[4]; + + if (!(cpu_feature2 & CPUID2_MON)) + return; + do_cpuid(5 /*CPUID_MONITOR*/, regs); + if ((regs[2/*ecx*/] & 0x03/*MON_EXT|MON_INTR*/) == 0x03/*both set*/) + cpu_ident_mwait_intr_ext = 1; +} + #ifdef XEN void (*cpu_idle_fn)(int) = cpu_idle_hlt; #else @@ -2747,6 +2787,7 @@ init386(first) cpu_probe_amdc1e(); cpu_probe_cmpxchg8b(); + cpu_probe_mwait_ext(); } #else @@ -3024,6 +3065,7 @@ init386(first) cpu_probe_amdc1e(); cpu_probe_cmpxchg8b(); + cpu_probe_mwait_ext(); } #endif diff -rup --exclude='*~' --exclude='*.patch' /sys/i386/include/acpica_machdep.h native_cx/i386/include/acpica_machdep.h --- sys/i386/include/acpica_machdep.h 2009-09-24 00:42:35.000000000 +0900 +++ sys/i386/include/acpica_machdep.h 2010-11-01 14:15:16.956638758 +0900 @@ -94,9 +94,11 @@ extern int acpi_release_global_lock(uint #define COMPILER_DEPENDENT_INT64 long long #define COMPILER_DEPENDENT_UINT64 unsigned long long #define ACPI_USE_NATIVE_DIVIDE +#define ACPI_USE_NATIVE_CX void acpi_SetDefaultIntrModel(int model); void acpi_cpu_c1(void); +void acpi_cpu_cx_native(uint16_t code, uint64_t arg0, uint8_t arg1); void *acpi_map_table(vm_paddr_t pa, const char *sig); void acpi_unmap_table(void *table); vm_paddr_t acpi_find_table(const char *sig); --Multipart=_Fri__15_Jul_2011_17_48_17_+0900_WC/_1oDFZjEbU.lx-- From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 15 14:33:00 2011 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 C24A2106566B for ; Fri, 15 Jul 2011 14:33:00 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB4D8FC1A for ; Fri, 15 Jul 2011 14:32:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p6FEWqBe066258; Sat, 16 Jul 2011 00:32:52 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 16 Jul 2011 00:32:52 +1000 (EST) From: Ian Smith To: Kevin Oberman In-Reply-To: Message-ID: <20110715231114.U5838@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_ibm fails to work on new laptop 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: Fri, 15 Jul 2011 14:33:00 -0000 On Thu, 14 Jul 2011, Kevin Oberman wrote: > On Jul 13, 2011 10:30 AM, "Ian Smith" wrote: > > > > On Mon, 11 Jul 2011 16:34:43 -0700, Kevin Oberman wrote: > > > > > I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm > > > is not functional. 'sysctl dev.acpi_ibm' > > > returns nothing. No volume control, though MUTE does work. > > > > Is the module actually loading? If so, verbose dmesg shpuld say like > > Preloaded elf module "/boot/kernel/acpi_ibm.ko" at 0xc103b2e0 > > and presumably whinge if it failed to load? > > > > > Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably > > > should change all "IBM references to LENOVO while I'm at it.) > > > I'll probably give this a shot, just to see if it works. > > > > Change where? No OEMID in /sys/dev/acpi_support/acpi_ibm.c at 8.2-R. > > > > cheers, Ian > Yes, it loads fine. I see the load message at boot and kldstat shows it. Hmm, yet acpi_ibm_attach() doesn't seem to get as far as setting up the sysctl tree? Can you post or point to a verbose dmesg? > I dumped the asl and it has the OEMID set to LENOVO, where.my T43 has IBM. Ah right, duh! Someone who groks ASL might like to peek at it. > At the start of the code is: > > #define _COMPONENT ACPI_OEM > ACPI_MODULE_NAME("IBM") > > I'm guessing that the OEMID and the ACPI_MODULE_NAME need to match. Could be. kldstat shows it's loaded the module, but something should complain if the dev either fails to probe or to then attach properly? !sysctl dev.acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 2124 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2124 dev.acpi_ibm.0.hotkey: 2180 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 6 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 0 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 26 31 29 -1 -1 -1 14 -1 acpi_ibm_probe() checks that %pnpinfo _HID=IBM0068 so if you are seeing acpi_ibm0: on acpi0 on boot, it seems it must be probing ok but failing to attach somehow? Hoping Lenovo haven't quit being 'IBM compatible' in this respect, just stumbling around for an hour till They Who Know get a spare minute :) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 15 21:24:56 2011 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 DCB8B1065675 for ; Fri, 15 Jul 2011 21:24:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9BB8FC22 for ; Fri, 15 Jul 2011 21:24:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA18933; Sat, 16 Jul 2011 00:24:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QhpsH-000ARz-9C; Sat, 16 Jul 2011 00:24:41 +0300 Message-ID: <4E20B015.5000701@FreeBSD.org> Date: Sat, 16 Jul 2011 00:24:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Kevin Oberman References: In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ian Smith Subject: Re: acpi_ibm fails to work on new laptop 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: Fri, 15 Jul 2011 21:24:56 -0000 on 14/07/2011 18:22 Kevin Oberman said the following: > #define _COMPONENT ACPI_OEM > ACPI_MODULE_NAME("IBM") > > I'm guessing that the OEMID and the ACPI_MODULE_NAME need to match. No. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 16 01:00:17 2011 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 55B1B106566B for ; Sat, 16 Jul 2011 01:00:16 +0000 (UTC) (envelope-from mygamejw@aol.com) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2038FC15 for ; Sat, 16 Jul 2011 01:00:15 +0000 (UTC) Received: from mtaout-da01.r1000.mx.aol.com (mtaout-da01.r1000.mx.aol.com [172.29.51.129]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id p6G0o1h9031492 for ; Fri, 15 Jul 2011 20:50:01 -0400 Received: from [192.168.2.4] (cpe-76-93-17-186.socal.res.rr.com [76.93.17.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-da01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5FA5FE00011A; Fri, 15 Jul 2011 20:50:00 -0400 (EDT) Message-Id: From: Mygamejw To: "jonathanince@aol.com" , "freebsd-acpi@FreeBSD.org" Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPod Mail 7E18) Date: Fri, 15 Jul 2011 17:49:17 -0700 X-Mailer: iPod Mail (7E18) x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:339523232:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33814e20e0387032 X-AOL-IP: 76.93.17.186 Cc: Subject: Newbbie Issue (JP) - installing FreeBSD 8.1 on a HP Notebook 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: Sat, 16 Jul 2011 01:00:17 -0000 I recently got FreeBSD 8.1 for a present and I went to install it on my wife's HP notebook. The issue I am having is related to a possible hacker who has gotten into her system. I have not flashed anything yet. I wanted to ask before I do because of my inexperience with FreeBSD. Any time that I try to boot the pc after pressing #6 option I get a crash notice saying the following at the end of a massive reset notice: init: not found in path /sbin/init:/sbin/ d/sysinstall panic: no init cpuid = 1 KDB: stack backtrace: #0 0xc08e0d07 at kdb_backtrace+0x47 #1 0xc08b1dc7 at panic+0x117 #2 0xc08694f0 at start_init+0x340 #3 0x0886d51 at fork_exit+0x91 #4 0xc0bcbf34 at fork_trampoline+0x8 This is what I see at boot time. CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS 638kB/3143488kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (root@almeida.cse.buffalo.edu, Fri Feb 18 01:25:00 UTC 2011) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x8e7781 data=0xdf7d4+0xa44e4 syms= [0x4+0x9a090+0x4+0xd32c32] Ok show LINES=24 acpi_load=YES autoboot_delay=NO bootfile=kernel comconsole_speed=9600 console=vidconsole currdev=cd0: hint.acpi.0.oem=HP hint.acpi.0.revision=2 hint.acpi.0.rsdp=0xf8480 hint.acpi.0.rsdt=0xbfed5b8d hint.acpi.0.xsdt=0x00000000bfed5bdd hint.acpi.0.xsdt_length=36 hint.apm.0.disabled=1 hint.apm.0.flags=0x20 hint.ata.0.at=isa hint.ata.0.irq=14 hint.ata.0.port=0x1F0 hint.ata.1.at=isa hint.ata.1.irq=15 hint.ata.1.port=0x170 hint.atkbd.0.at=atkbdc hint.atkbd.0.irq=1 hint.atkbdc.0.at=isa hint.atkbd.0.port=0x060 hint.atrtc.0.at=isa hint.atrtc.0.irq=8 hint.atrtc.0.port=0x70 hint.fd.0.at=fdc0 hint.fd.0.drive=0 hint.fd.1.at=fdc0 hint.fd.1.drive=1 hint.fdc.0.at=isa hint.fdc.0.drq=2 hint.fdc.0.irq=6 hint.fdc.0.port=0x3F0 hint.ppc.0.at=isa hint.ppc.0.irq=7 hint.psm.0.at=atkbdc hint.psm.0.irq=12 hint.sc.0.at=isa hint.sc.0.flags=0x100 hint.uart.0.at=isa hint.uart.0.flags=0x10 hint.uart.0.irq=4 hint.uart.0.port=0x3F8 hint.uart.1.at=isa hint.uart.1.irq=3 hint.uart.1.port=0x2F8 interpret=Ok kernel=kernel kernel_options= loaddev=cd0: loader_conf_files=/boot/device.hints /boot/loader.conf /boot/ loader.conf.local mac_ifoff=ON module_path=/boot/kernel;/boot/modules prompt=${interpret} smbios.bios.reldate=06/16/2008 smbios.bios.vendor=Hewlett-Packard smbios.bios.version=F.58 smbios.chassis.maker=Quanta smbios.chassis.serial=None smbios.chassis.tag= smbios.chassis.version=N/A smbios.memory.enabled=3145728 smbios.planar.maker=Quanta smbios.planar.product=30D2 smbios.planar.serial=None smbios.planar.version=79.2E smbios.socket.enabled=1 smbios.socket.populated=1 smbios.system.maker=Hewlett-Packard smbios.system.product=HP Pavilion dv6700 Notebook PC smbios.system.serial=CNF8032HV9 smbios.system.uuid=434e4638-3033-3248-5639-001e68099764 smbios.system.version=Rev 1 smbios.version=2.4 Ok lsmod 0x400000: /boot/kernel/kernel (elf kernel, 0xbd97b4) modules: x86bios.1 elink.1 io.1 hptrr.1 ufs.1 kernel_mac_support.4 krpc.1 nfslockd.1 nfssvc.1 nfsserver.1 nfs.1 nfslock.1 nfs_common.1 wlan_sta.1 wlan_ratectl_none.1 wlan.1 wlan_wep.1 wlan_tkip.1 wlan_ccmp. 1 wlan_amrr.1 if_vlan.3 if_gif.1 if_firewire.1 if_faith.1 ether.1 sem. 1 sysvshm.1 sysvsem.1 sysvmsg.1 firmware.1 kernel.802000 cd9660.1 isa. 1 pseudofs.1 procfs.1 msdosfs.1 usb_quirk.1 ums.1 ukbd.1 uhid.1 ucom.1 nvscom.1 uvisor.1 uslcom.1 uplcom.1 ulpt.1 uipaq.1 uftdi.1 ubsa.1 uark. 1 u3g.1 zyd.1 ural.1 uath.1 rum.1 uether.1 udav.1 rue.1 kue.1 cue.1 cdce.1 axe.1 aue.1 uhub.1 usb.1 usb_linux.1 urio.1 umass.1 random.1 ppbus.1 pci.1 pccard.1 null.1 mpt_user.1 mpt_raid.1 mpt.1 mpt_cam.1 mpt_core.1 miibus.1 mfi.1 mem.1 isp.1 fwip.1 fwe.1 firewire.1 splash.1 exca.1 dcons.2 dcons_crom.1 cardbus.1 bt.1 ath.1 ast.1 afd.1 acd.1 ataraid.1 ad.1 ata_via.1 ata_sis.1 ata_sii.1 ata_serverworks.1 ata_promise.1 ata_nvidia.1 ata_netcell.1 ata_national.1 ata_micron.1 ata_marvell.1 ata_jmicron.1 ata_ite.1 ata_intel.1 ata_highpoint.1 ata_cyrix.1 ata_cypress.1 ata_cenatek.1 ata_ati.1 ata_amd.1 ata_adaptec.1 ata_ali.1 ata_acard.1 ata_ahci.1 atapci.1 ata.1 ahc.1 ahd.1 ahd_pci.1 ahc_pci.1 ahc_isa.1 ahc_eisa.1 agp.1 acpi_pci.1 acpi.1 scsi_low.1 cam.1 0xfd97b4: /boot/mfsroot (mfs_root, 0x438000) If you need further information please let me know. Ok lsdev cd devices: cd0: Device 0x0 disk device: disk0: BIOS drive C: disk0s1:NTFS/HPFS pxe devices: Thanks, JP From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 16 08:07:42 2011 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 870E4106564A; Sat, 16 Jul 2011 08:07:42 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1898FC18; Sat, 16 Jul 2011 08:07:40 +0000 (UTC) Received: by vws18 with SMTP id 18so1839156vws.13 for ; Sat, 16 Jul 2011 01:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=245tk7DeLd/TAp2e1QvoDtUy2Rr964PHLbq6ml/ykBk=; b=wxGcJpnE+gYiw8VrPgpRzmZbhZC5tP4d1cTqhx9GHmedOmi9FcprYWuAOF1NiaPS7L Qq9W3jqIKWKgcS8i/kLlPx8EukWOfaBqCe7ujbUSg7ptP+Wwz3RIUhCjej0qwtUUJmyf 0SxkKB5XC+am7fTLY0MPGhEFj6/POjhvvflv4= MIME-Version: 1.0 Received: by 10.52.177.165 with SMTP id cr5mr990048vdc.434.1310803659737; Sat, 16 Jul 2011 01:07:39 -0700 (PDT) Received: by 10.52.188.193 with HTTP; Sat, 16 Jul 2011 01:07:39 -0700 (PDT) In-Reply-To: <20110715174817.9b933756.taku@tackymt.homeip.net> References: <20110713114521.9f684b01.taku@tackymt.homeip.net> <201107131202.53344.jkim@FreeBSD.org> <20110715174817.9b933756.taku@tackymt.homeip.net> Date: Sat, 16 Jul 2011 11:07:39 +0300 Message-ID: From: Vitaly Magerya To: Taku YAMAMOTO Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Sat, 16 Jul 2011 08:07:42 -0000 Taku YAMAMOTO wrote: > Maybe we have to tell the BIOS that we are going to utilize _CST via SMI. > In fact, the major difference between mine and jkim's is that in mine > I took the following snippet (which we can find in acpi_cpu_startup_cx > function, living in sys/dev/acpica/acpi_cpu.c) out of #ifdef notyet. > > -#ifdef notyet > /* Signal platform that we can handle _CST notification. */ > if (!cpu_cx_generic && cpu_cst_cnt != 0) { > ACPI_LOCK(acpi); > AcpiOsWritePort(cpu_smi_cmd, cpu_cst_cnt, 8); > ACPI_UNLOCK(acpi); > } > -#endif > > Vitaly, could you remove the above-mentioned #ifdef-#endif pair (to activate > the code inbetween) and test jkim's patch again? It hangs on the same spot. >> Actually, I abandoned the patches and I am thinking about rewriting it >> from scratch, e.g., refactoring MI/MD support code >> (dev/acpica/acpi_cpu.c -> machine/machdep.c & acpica/acpi_machdep.c). >> Unfortunately, I don't have much time nor hardware to test, so it >> won't happen any time soon. Sorry. >> >> If anyone wants to pick it up from here, please feel free. > > [...] > > I will happily test your new patches next time. I'll provide any testing help needed as well.