From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 31 11:06:55 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84BA51065670 for ; Mon, 31 Mar 2008 11:06:55 +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 6BB828FC14 for ; Mon, 31 Mar 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2VB6tpj038815 for ; Mon, 31 Mar 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2VB6sE1038811 for freebsd-acpi@FreeBSD.org; Mon, 31 Mar 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2008 11:06:54 GMT Message-Id: <200803311106.m2VB6sE1038811@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, 31 Mar 2008 11:06:55 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/114113 acpi [acpi] [patch] ACPI kernel panic during S3 suspend / r o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o bin/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 21 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/114649 acpi [patch][acpi] panic: recursed on non-recursive mutex o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin 20 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 1 05:00:32 2008 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 CEC5C10656DA for ; Tue, 1 Apr 2008 05:00:32 +0000 (UTC) (envelope-from kent@khauser.net) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id AB57B8FC28 for ; Tue, 1 Apr 2008 05:00:31 +0000 (UTC) (envelope-from kent@khauser.net) Received: by wx-out-0506.google.com with SMTP id i29so2155727wxd.7 for ; Mon, 31 Mar 2008 22:00:31 -0700 (PDT) Received: by 10.114.151.13 with SMTP id y13mr11422581wad.148.1207024399938; Mon, 31 Mar 2008 21:33:19 -0700 (PDT) Received: by 10.114.15.6 with HTTP; Mon, 31 Mar 2008 21:33:19 -0700 (PDT) Message-ID: <6004effe0803312133l4283e48dy2418a689633d3d16@mail.gmail.com> Date: Mon, 31 Mar 2008 18:33:19 -1000 From: "Kent Hauser" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wake-on-LAN requires hard power-off 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, 01 Apr 2008 05:00:33 -0000 Hi, I'm trying to get wake-on-lan working on a dual-boot (FreeBSD 7-stable/XP) machine & am having a problem. I am using an eMachines MB with a Intel PRO/1000 NIC. I enabled WOL using the Intel utility. Under XP, WOL is just fine. Works as expected. Under FreeBSD, after "halt -p" the HUB LED comes on (low-speed) indicating NIC power, but the machine doesn't respond to WOL requests. However, if I remove the power cord from the machine for a while, it will restart with WOL. I'm running 7-stable. I don't have any information about previous versions. Thanks for the input. Kent From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 3 08:30:09 2008 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 BC40D106564A for ; Thu, 3 Apr 2008 08:30:09 +0000 (UTC) (envelope-from lists.ampmouse@ampmouse.net) Received: from wsu.ampmouse.net (res121121.resnet.wsu.edu [134.121.121.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF0E8FC22 for ; Thu, 3 Apr 2008 08:30:09 +0000 (UTC) (envelope-from lists.ampmouse@ampmouse.net) Received: from lt1.ampmouse.net ([192.168.100.5]) by wsu.ampmouse.net (8.13.8/8.13.8) with ESMTP id m338EAp5054946 for ; Thu, 3 Apr 2008 01:14:10 -0700 (PDT) (envelope-from lists.ampmouse@ampmouse.net) Message-ID: <47F491D1.6020103@ampmouse.net> Date: Thu, 03 Apr 2008 01:14:09 -0700 From: Andrew Pilloud User-Agent: Thunderbird 2.0.0.9 (X11/20080107) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: OS Suspend to disk (Google Summer of Code) 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, 03 Apr 2008 08:30:09 -0000 Hello, I am working on a project proposal for Google Summer of Code. I am hoping to be able to implement OS based suspend to disk for FreeBSD. Anyway, I have a few questions and a request: 1. Is anyone currently working on OS based suspend to disk? (I'm pretty sure it's no, but I don't want to duplicate anyone else's efforts) 2. Would anyone be interested in being a mentor for this project? 3. Any feedback on my application would be appreciated. My application is here: http://www.ampmouse.com/code/8-gsoc2008/24-application.html Thanks, Andrew Pilloud From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 3 19:11:41 2008 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 AB144106566B for ; Thu, 3 Apr 2008 19:11:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 25A8F8FC19 for ; Thu, 3 Apr 2008 19:11:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 237827660-1834499 for multiple; Thu, 03 Apr 2008 15:12:17 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m33JBX66095916; Thu, 3 Apr 2008 15:11:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Thu, 3 Apr 2008 14:05:42 -0400 User-Agent: KMail/1.9.7 References: <47F491D1.6020103@ampmouse.net> In-Reply-To: <47F491D1.6020103@ampmouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804031405.42440.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 03 Apr 2008 15:11:34 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6568/Thu Apr 3 12:12:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: OS Suspend to disk (Google Summer of Code) 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, 03 Apr 2008 19:11:41 -0000 On Thursday 03 April 2008 04:14:09 am Andrew Pilloud wrote: > Hello, > > I am working on a project proposal for Google Summer of Code. I am > hoping to be able to implement OS based suspend to disk for FreeBSD. > Anyway, I have a few questions and a request: > > 1. Is anyone currently working on OS based suspend to disk? (I'm pretty > sure it's no, but I don't want to duplicate anyone else's efforts) > 2. Would anyone be interested in being a mentor for this project? > 3. Any feedback on my application would be appreciated. My application > is here: > http://www.ampmouse.com/code/8-gsoc2008/24-application.html Hmm, the idea of reading the saved image in during early boot is a bit different. One thing to note is that / does have to be mounted for rc scripts to run (so at least one filesystem will already be mounted). One thing that might make it easier though, is to just require a separate disk partition (like swap, but a dedicated one, not reusing swap) to dump the RAM image into. Later on you could extend it to use a pre-allocated file on a filesystem perhaps, but using a dedicated partition for now might reduce the work needed. I think if you can dump all of RAM to a suspend partition then it actually is not too hard to make the loader just read that into RAM with some sort of header to give an entry point (and to validate it). Some things that would be really nice for S4 suspend though would be to have the system try to quiesce things more during suspend than it does now. For example, it would be nice if suspend would flush pending writes to disk and possibly mark filesystems as clean before actually going to sleep to minimize data loss (this would be useful even for S1 or S3 if the battery runs out while suspended). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 3 20:07:02 2008 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 3DB0E106564A; Thu, 3 Apr 2008 20:07:02 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 97C858FC15; Thu, 3 Apr 2008 20:07:01 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 15:44:53 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 7F43E116FE; Thu, 3 Apr 2008 15:44:53 -0400 (EDT) Date: Thu, 3 Apr 2008 15:44:53 -0400 From: Ed Maste To: bug-followup@freebsd.org, freebsd-acpi@freebsd.org Message-ID: <20080403194453.GA46525@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 03 Apr 2008 19:44:53.0730 (UTC) FILETIME=[300BCC20:01C895C3] Cc: Subject: Re: kern/114649: [patch][acpi] panic: recursed on non-recursive mutex 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, 03 Apr 2008 20:07:02 -0000 I have this same problem on my thinkpad T20. kern/114113 is the same issue. From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 3 20:10:04 2008 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFA82106564A for ; Thu, 3 Apr 2008 20:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 816FA8FC14 for ; Thu, 3 Apr 2008 20:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m33KA4OR031548 for ; Thu, 3 Apr 2008 20:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m33KA4u3031547; Thu, 3 Apr 2008 20:10:04 GMT (envelope-from gnats) Date: Thu, 3 Apr 2008 20:10:04 GMT Message-Id: <200804032010.m33KA4u3031547@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Ed Maste Cc: Subject: Re: kern/114649: [patch][acpi] panic: recursed on non-recursive mutex X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ed Maste List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 20:10:04 -0000 The following reply was made to PR kern/114649; it has been noted by GNATS. From: Ed Maste To: bug-followup@freebsd.org, freebsd-acpi@freebsd.org Cc: Subject: Re: kern/114649: [patch][acpi] panic: recursed on non-recursive mutex Date: Thu, 3 Apr 2008 15:44:53 -0400 I have this same problem on my thinkpad T20. kern/114113 is the same issue. From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 3 23:43:13 2008 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 863F9106566C for ; Thu, 3 Apr 2008 23:43:13 +0000 (UTC) (envelope-from lists.ampmouse@ampmouse.net) Received: from wsu.ampmouse.net (res121121.resnet.wsu.edu [134.121.121.121]) by mx1.freebsd.org (Postfix) with ESMTP id 215228FC19 for ; Thu, 3 Apr 2008 23:43:13 +0000 (UTC) (envelope-from lists.ampmouse@ampmouse.net) Received: from lt1.ampmouse.net ([192.168.100.5]) by wsu.ampmouse.net (8.13.8/8.13.8) with ESMTP id m33NhBtt024056; Thu, 3 Apr 2008 16:43:11 -0700 (PDT) (envelope-from lists.ampmouse@ampmouse.net) Message-ID: <47F56B93.2080808@ampmouse.net> Date: Thu, 03 Apr 2008 16:43:15 -0700 From: Andrew Pilloud User-Agent: Thunderbird 2.0.0.9 (X11/20080107) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <47F491D1.6020103@ampmouse.net> <200804031405.42440.jhb@freebsd.org> In-Reply-To: <200804031405.42440.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: OS Suspend to disk (Google Summer of Code) 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, 03 Apr 2008 23:43:13 -0000 John Baldwin wrote: > Hmm, the idea of reading the saved image in during early boot is a bit > different. One thing to note is that / does have to be mounted for rc > scripts to run (so at least one filesystem will already be mounted). One > thing that might make it easier though, is to just require a separate disk > partition (like swap, but a dedicated one, not reusing swap) to dump the RAM > image into. Later on you could extend it to use a pre-allocated file on a > filesystem perhaps, but using a dedicated partition for now might reduce the > work needed. I think if you can dump all of RAM to a suspend partition then > it actually is not too hard to make the loader just read that into RAM with > some sort of header to give an entry point (and to validate it). > > Some things that would be really nice for S4 suspend though would be to have > the system try to quiesce things more during suspend than it does now. For > example, it would be nice if suspend would flush pending writes to disk and > possibly mark filesystems as clean before actually going to sleep to minimize > data loss (this would be useful even for S1 or S3 if the battery runs out > while suspended). Thanks for the advice. I don't think / being mounted read only will be a problem. As long as the disk is not modified everything should be fine. A dedicated partition would make things easier, especially with resuming in the boot loader. There seem to be different advantages to both ways of resuming the system. Microsoft products resume in the boot loader, and Linux in a script just after the kernel loads. This seems like something that could turn into a bikeshed debate rather quickly. I think the best way to determine which is better is to implement them both. As for the file systems, I don't really know what more you can do to quiesce the system then is already being done. When you suspend, the script rc.suspend is suppose to run. That script runs sync, which should take care of flushing pending disk writes. I don't know if marking a file system clean is wise or even possible without completely un-mounting it. Andrew Pilloud From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 4 13:29:55 2008 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 0B751106574F for ; Fri, 4 Apr 2008 13:29:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0428C8FC14 for ; Fri, 4 Apr 2008 13:29:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 6AAAD1A4D84; Fri, 4 Apr 2008 06:29:52 -0700 (PDT) From: John Baldwin To: Andrew Pilloud Date: Fri, 4 Apr 2008 09:19:05 -0400 User-Agent: KMail/1.9.7 References: <47F491D1.6020103@ampmouse.net> <200804031405.42440.jhb@freebsd.org> <47F56B93.2080808@ampmouse.net> In-Reply-To: <47F56B93.2080808@ampmouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804040919.05824.jhb@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: OS Suspend to disk (Google Summer of Code) 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, 04 Apr 2008 13:29:55 -0000 On Thursday 03 April 2008 07:43:15 pm Andrew Pilloud wrote: > John Baldwin wrote: > > Hmm, the idea of reading the saved image in during early boot is a bit > > different. One thing to note is that / does have to be mounted for rc > > scripts to run (so at least one filesystem will already be mounted). One > > thing that might make it easier though, is to just require a separate > > disk partition (like swap, but a dedicated one, not reusing swap) to dump > > the RAM image into. Later on you could extend it to use a pre-allocated > > file on a filesystem perhaps, but using a dedicated partition for now > > might reduce the work needed. I think if you can dump all of RAM to a > > suspend partition then it actually is not too hard to make the loader > > just read that into RAM with some sort of header to give an entry point > > (and to validate it). > > > > Some things that would be really nice for S4 suspend though would be to > > have the system try to quiesce things more during suspend than it does > > now. For example, it would be nice if suspend would flush pending writes > > to disk and possibly mark filesystems as clean before actually going to > > sleep to minimize data loss (this would be useful even for S1 or S3 if > > the battery runs out while suspended). > > Thanks for the advice. I don't think / being mounted read only will be a > problem. As long as the disk is not modified everything should be fine. > A dedicated partition would make things easier, especially with resuming > in the boot loader. I think making things easier is good for a first pass to make it more feasible of getting something working during the summer. > There seem to be different advantages to both ways of resuming the > system. Microsoft products resume in the boot loader, and Linux in a > script just after the kernel loads. This seems like something that could > turn into a bikeshed debate rather quickly. I think the best way to > determine which is better is to implement them both. Both is probably fine. I would aim to make things as simple as possible at first though. > As for the file systems, I don't really know what more you can do to > quiesce the system then is already being done. When you suspend, the > script rc.suspend is suppose to run. That script runs sync, which should > take care of flushing pending disk writes. I don't know if marking a > file system clean is wise or even possible without completely > un-mounting it. It's quite possible. Filesystems just have a dirty bit usually in a superblock-type thing that you can clear if all pending writes are flushed. Something like this would need to be done via a kernel event I think though rather than just calling sync from userland. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 4 15:44:11 2008 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 55A33106566B for ; Fri, 4 Apr 2008 15:44:11 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.185]) by mx1.freebsd.org (Postfix) with ESMTP id 74FA08FC15 for ; Fri, 4 Apr 2008 15:44:10 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: by gv-out-0910.google.com with SMTP id n40so55170gve.39 for ; Fri, 04 Apr 2008 08:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; bh=G229xbUXyIZdD1yx6Sao6Mqv0Sg39+tyyGByOzHQAt4=; b=HiokHH8mHbTwTEAtdFEJnVasBOyrcZbj1WAstTbNwf5yPyosYB0YnaLD+OrP6dWMtOFFTtLQWCQhDPo7R1JqIKwZYTmWAOMry+OkRs5ZtsyX5XNgJI6ZDQZoLp4DE0zmn0MlmCZ9nVlsrfPcGKAGYBd9s4vQBlWNkzG2EoJqNyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=MMNrt4vFGnR8fUAZEf5zrUYzyLO3ORUXilvgMzck4Slw1p81D1qqPBL4Gpi1l94a7OnUiK/672OJdI5kdM5E2ELYHjPrZhE9YUC8CB5u5ihjbSS/BZPSvK2NXuie+LN/g7He2fcjYd8PsuxigoVF5EiSva/fYuM61Gqe1pTxhUM= Received: by 10.143.37.20 with SMTP id p20mr985300wfj.236.1207323846477; Fri, 04 Apr 2008 08:44:06 -0700 (PDT) Received: by 10.70.27.5 with HTTP; Fri, 4 Apr 2008 08:44:06 -0700 (PDT) Message-ID: <5fbf03c20804040844q22875ac8nbbc3fae121d3eac8@mail.gmail.com> Date: Fri, 4 Apr 2008 17:44:06 +0200 From: "Spil Oss" To: freebsd-acpi@freebsd.org, freebsd-questions@freebsd.org In-Reply-To: <5fbf03c20804040812t5fdf8065ubf46d6420358595@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4631_9949392.1207323846206" References: <5fbf03c20804040812t5fdf8065ubf46d6420358595@mail.gmail.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problem with lid on Dell D400 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2008 15:44:11 -0000 ------=_Part_4631_9949392.1207323846206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On a Dell D400 notebook (Pentium-M 1.4GHz, Intel 855GM, ICH4M) running FreeBSD 7.0 #0 Closing the lid switches off the display, opening the lid does not switch the display back on. Very annoying. The machine is fully functional otherwise (accessed via ssh). Noticed this first on a vanilla FreeBSD-7.0 #0 install, the optimized kernel seems to behave the same. In sysctl I noticed after closing and opening the lid hw.acpi.lid_switch_state: NONE but I have not checked the status of this sysctl before I closed the lid. dmesg output is not of boot -v, but of regular boot I wouldn't care if the lid doesn't have acpi features (e.g. suspend on lid close), but I'd like the screen to switch off for additional battery-life. Hope someone can help me! Kind regards, Spil ------=_Part_4631_9949392.1207323846206 Content-Type: text/plain; name=bjs-DellD400.dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_femw0pub Content-Disposition: attachment; filename=bjs-DellD400.dmesg Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtUkVMRUFTRSAjMDogRnJpIEFwciAgNCAwNzoy MjoyMiBDRVNUIDIwMDgKICAgIHJvb3RAeHh4eHh4eHh4Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0JF QVNUSUU3MApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkg MApDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgTSBwcm9jZXNzb3IgMTQwME1IeiAoMTM5OC44Mi1N SHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY5NSAg U3RlcHBpbmcgPSA1CiAgRmVhdHVyZXM9MHhhN2U5ZjliZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNS LE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFRNLFBCRT4KICBGZWF0dXJlczI9MHgxODA8RVNULFRNMj4KcmVhbCBtZW1v cnkgID0gNTM1NDUzNjk2ICg1MTAgTUIpCmF2YWlsIG1lbW9yeSA9IDUxNDQ2MTY5NiAoNDkwIE1C KQphY3BpMDogPERFTEwgQ1BpIFIgID4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFtJVEhSRUFEXQph Y3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgOWZjMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRp b24gb2YgMTAwMDAwLCAxZmRmMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3Qi IGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0 aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApjcHUwOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRy b2w+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNw dTAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250 cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBM aWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkw CmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3Qt UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2lfbGluazE6IEJJT1MgSVJR IDExIGZvciAwLjMxLklOVEIgaXMgaW52YWxpZApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MApwY2kwOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAwLjMgKG5vIGRyaXZlciBhdHRh Y2hlZCkKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHhjMDAwLTB4YzAw NyBtZW0gMHhmMDAwMDAwMC0weGY3ZmZmZmZmLDB4ZmFmODAwMDAtMHhmYWZmZmZmZiBpcnEgMTEg YXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFncDA6IDxJbnRlbCA4Mjg1eE0gKDg1eEdNIEdNQ0gpIFNW R0EgY29udHJvbGxlcj4gb24gdmdhcGNpMAphZ3AwOiBkZXRlY3RlZCA4OTJrIHN0b2xlbiBtZW1v cnkKYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAxMjhNCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBk aXNwbGF5PiBtZW0gMHhlODAwMDAwMC0weGVmZmZmZmZmLDB4ZmFmMDAwMDAtMHhmYWY3ZmZmZiBh dCBkZXZpY2UgMi4xIG9uIHBjaTAKdWhjaTA6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29u dHJvbGxlciBVU0ItQT4gcG9ydCAweGJmODAtMHhiZjlmIGlycSAxMSBhdCBkZXZpY2UgMjkuMCBv biBwY2kwCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1aGNpMDogW0lUSFJFQURdCnVzYjA6IDxJbnRl bCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNiMDogVVNC IHJldmlzaW9uIDEuMAp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IwCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1aGNpMTogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9s bGVyIFVTQi1CPiBwb3J0IDB4YmY0MC0weGJmNWYgaXJxIDExIGF0IGRldmljZSAyOS4xIG9uIHBj aTAKdWhjaTE6IFtHSUFOVC1MT0NLRURdCnVoY2kxOiBbSVRIUkVBRF0KdXNiMTogPEludGVsIDgy ODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2IxOiBVU0IgcmV2 aXNpb24gMS4wCnVodWIxOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkCnVoY2kyOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIg VVNCLUM+IHBvcnQgMHhiZjIwLTB4YmYzZiBpcnEgMTEgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1 aGNpMjogW0dJQU5ULUxPQ0tFRF0KdWhjaTI6IFtJVEhSRUFEXQp1c2IyOiA8SW50ZWwgODI4MDFE QiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9uIHVoY2kyCnVzYjI6IFVTQiByZXZpc2lv biAxLjAKdWh1YjI6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNiMgp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKZWhjaTA6IDxJbnRlbCA4MjgwMURCL0wvTSAoSUNINCkgVVNCIDIuMCBjb250cm9s bGVyPiBtZW0gMHhmYWVmZmMwMC0weGZhZWZmZmZmIGlycSAxMSBhdCBkZXZpY2UgMjkuNyBvbiBw Y2kwCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQplaGNpMDogW0lUSFJFQURdCnVzYjM6IEVIQ0kgdmVy c0lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAg dXNiMSB1c2IyCnVzYjM6IDxJbnRlbCA4MjgwMURCL0wvTSAoSUNINCkgVVNCIDIuMCBjb250cm9s bGVyPiBvbiBlaGNpMAp1c2IzOiBVU0IgcmV2aXNpb24gMi4wCnVodWIzOiA8SW50ZWwgRUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjMKdWh1YjM6 IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaWIxOiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMQpiZ2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJv bGxlciwgQVNJQyByZXYuIDB4MzAwMT4gbWVtIDB4ZmNmZjAwMDAtMHhmY2ZmZmZmZiBpcnEgMTEg YXQgZGV2aWNlIDAuMCBvbiBwY2kxCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZ2UwCmJyZ3BoeTA6 IDxCQ001NzA1IDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gUEhZIDEgb24gbWlpYnVzMApicmdwaHkw OiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJh c2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvCmJnZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjBkOjU2 OjZkOjlhOjliCmJnZTA6IFtJVEhSRUFEXQpjYmIwOiA8VEk3NTEwIFBDSS1DYXJkQnVzIEJyaWRn ZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kxCmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAK cGNjYXJkMDogPDE2LWJpdCBQQ0NhcmQgYnVzPiBvbiBjYmIwCmNiYjA6IFtJVEhSRUFEXQpjYmIx OiA8VEk3NjEwIFBDSS1DYXJkQnVzIEJyaWRnZT4gaXJxIDExIGF0IGRldmljZSAxLjEgb24gcGNp MQpjYXJkYnVzMTogPENhcmRCdXMgYnVzPiBvbiBjYmIxCnBjY2FyZDE6IDwxNi1iaXQgUENDYXJk IGJ1cz4gb24gY2JiMQpjYmIxOiBbSVRIUkVBRF0KZndvaGNpMDogPDEzOTQgT3BlbiBIb3N0IENv bnRyb2xsZXIgSW50ZXJmYWNlPiBtZW0gMHhmY2ZlZjgwMC0weGZjZmVmZmZmLDB4ZmNmZTgwMDAt MHhmY2ZlYmZmZiBpcnEgMTEgYXQgZGV2aWNlIDEuMiBvbiBwY2kxCmZ3b2hjaTA6IFtGSUxURVJd CmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAxLjEwIChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2No cm9ub3VzIGNoYW5uZWxzIGlzIDQuCmZ3b2hjaTA6IEVVSTY0IDMyOjRmOmMwOjAwOjFmOjU0Ojc4 OjEwCmZ3b2hjaTA6IFBoeSAxMzk0YSBhdmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDog TGluayBTNDAwLCBtYXhfcmVjIDIwNDggYnl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVX aXJlKSBidXM+IG9uIGZ3b2hjaTAKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24g ZmlyZXdpcmUwCmRjb25zX2Nyb20wOiA8ZGNvbnMgY29uZmlndXJhdGlvbiBST00+IG9uIGZpcmV3 aXJlMApkY29uc19jcm9tMDogYnVzX2FkZHIgMHgxMTM4MDAwCmZ3b2hjaTA6IEluaXRpYXRlIGJ1 cyByZXNldApmd29oY2kwOiBCVVMgcmVzZXQKZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBn ZW49MSwgQ1lDTEVNQVNURVIgbW9kZQpwY2kxOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2Ug MS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmlj ZSAzMS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJ Q0g0IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3 NywweDM3NiwweGJmYTAtMHhiZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBj aGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEgY2hhbm5lbCAx PiBvbiBhdGFwY2kwCmF0YTE6IFtJVEhSRUFEXQpwY2kwOiA8bXVsdGltZWRpYSwgYXVkaW8+IGF0 IGRldmljZSAzMS41IChubyBkcml2ZXIgYXR0YWNoZWQpCmFjcGlfdHowOiA8VGhlcm1hbCBab25l PiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4 NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJF QURdCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9D S0VEXQpwc20wOiBbSVRIUkVBRF0KcHNtMDogbW9kZWwgR2xpZGVQb2ludCwgZGV2aWNlIElEIDAK cG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAw LTB4Y2Q3ZmYsMHhjZDgwMC0weGNkZmZmLDB4Y2UwMDAtMHhjZTdmZiwweGNlODAwLTB4Y2VmZmYs MHhjZjAwMC0weGNmN2ZmLDB4Y2Y4MDAtMHhjZmZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBw b3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3VudGVy ICJUU0MiIGZyZXF1ZW5jeSAxMzk4ODE4MDc2IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0 aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKaXBmdzIgKCtpcHY2KSBpbml0aWFsaXplZCwgZGl2ZXJ0IGVu YWJsZWQsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBkaXNhYmxlZCwgZGVmYXVsdCB0byBkZW55LCBs b2dnaW5nIGxpbWl0ZWQgdG8gNSBwYWNrZXRzL2VudHJ5IGJ5IGRlZmF1bHQKZmlyZXdpcmUwOiAx IG5vZGVzLCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1h bmFnZXIgMCAobWUpCmFkMDogMzgxNTRNQiA8SFRTNTQ4MDQwTTlBVDAwIE1HMk9BNTNBPiBhdCBh dGEwLW1hc3RlciBVRE1BMTAwClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQw czFhCmJnZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAo= ------=_Part_4631_9949392.1207323846206 Content-Type: text/plain; name=bjs-DellD400.sysctlhwacpi Content-Transfer-Encoding: base64 X-Attachment-Id: f_femw0t2l Content-Disposition: attachment; filename=bjs-DellD400.sysctlhwacpi aHcuYWNwaS5zdXBwb3J0ZWRfc2xlZXBfc3RhdGU6IFMxIFMzIFM0IFM1Cmh3LmFjcGkucG93ZXJf YnV0dG9uX3N0YXRlOiBTNQpody5hY3BpLnNsZWVwX2J1dHRvbl9zdGF0ZTogUzEKaHcuYWNwaS5s aWRfc3dpdGNoX3N0YXRlOiBOT05FCmh3LmFjcGkuc3RhbmRieV9zdGF0ZTogUzEKaHcuYWNwaS5z dXNwZW5kX3N0YXRlOiBTMwpody5hY3BpLnNsZWVwX2RlbGF5OiAxCmh3LmFjcGkuczRiaW9zOiAx Cmh3LmFjcGkudmVyYm9zZTogMApody5hY3BpLmRpc2FibGVfb25fcmVib290OiAwCmh3LmFjcGku aGFuZGxlX3JlYm9vdDogMApody5hY3BpLnJlc2V0X3ZpZGVvOiAwCmh3LmFjcGkuY3B1LmN4X2xv d2VzdDogQzEKaHcuYWNwaS5hY2xpbmU6IDEKaHcuYWNwaS5iYXR0ZXJ5LmxpZmU6IDEwMApody5h Y3BpLmJhdHRlcnkudGltZTogLTEKaHcuYWNwaS5iYXR0ZXJ5LnN0YXRlOiAwCmh3LmFjcGkuYmF0 dGVyeS51bml0czogMQpody5hY3BpLmJhdHRlcnkuaW5mb19leHBpcmU6IDUKaHcuYWNwaS50aGVy bWFsLm1pbl9ydW50aW1lOiAwCmh3LmFjcGkudGhlcm1hbC5wb2xsaW5nX3JhdGU6IDEwCmh3LmFj cGkudGhlcm1hbC51c2VyX292ZXJyaWRlOiAwCmh3LmFjcGkudGhlcm1hbC50ejAudGVtcGVyYXR1 cmU6IDMzLjVDCmh3LmFjcGkudGhlcm1hbC50ejAuYWN0aXZlOiAtMQpody5hY3BpLnRoZXJtYWwu dHowLnBhc3NpdmVfY29vbGluZzogMApody5hY3BpLnRoZXJtYWwudHowLnRoZXJtYWxfZmxhZ3M6 IDAKaHcuYWNwaS50aGVybWFsLnR6MC5fUFNWOiAtMQpody5hY3BpLnRoZXJtYWwudHowLl9IT1Q6 IC0xCmh3LmFjcGkudGhlcm1hbC50ejAuX0NSVDogOTkuMEMKaHcuYWNwaS50aGVybWFsLnR6MC5f QUN4OiAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMSAtMQo= ------=_Part_4631_9949392.1207323846206-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 5 11:36:45 2008 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 B68051065673 for ; Sat, 5 Apr 2008 11:36:45 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6518F8FC13 for ; Sat, 5 Apr 2008 11:36:45 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so799706pyb.10 for ; Sat, 05 Apr 2008 04:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent:sender; bh=iCwXCdDyPVt1OcB3Ai8OvrKZxgPgozArLEmGSJ/yWiw=; b=t6E3Cz9XLrJXlhbX333LuOlvKj43mmzOOtKXrGPxdjZvsWJzFPTgJGjYnMbhF1QWrLOYfCzSDyADmcgk7auIR397+/j3RJKTFEu1mz7teBeopNEzYNnq+OdGGRT0cmv9SqR/i4wCpc/GbxwInprn2GgBY6jDT3Qyvv20ruTQndk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent:sender; b=DvtL7LhTAIwyG54KOkmBGg1ZMH1snB/zg1JOmeVg3qZvOu5aPCxxm4Y4kTfc+AUkPp+JHnOQMV/VAfEfnzoj+cfC8U+AFFWOnvkeLRUCGp8ajDN2bZdz2IVqjg4ZkfM/aZ2aXf9cLXN+fhDw21xm3M3lXlZE/1zgfQYTRjACvIQ= Received: by 10.65.59.11 with SMTP id m11mr4020633qbk.27.1207395404214; Sat, 05 Apr 2008 04:36:44 -0700 (PDT) Received: from fnop.net ( [89.214.237.179]) by mx.google.com with ESMTPS id o30sm1639727ugd.84.2008.04.05.04.36.40 (version=SSLv3 cipher=OTHER); Sat, 05 Apr 2008 04:36:43 -0700 (PDT) Date: Sat, 5 Apr 2008 12:36:31 +0100 From: Rui Paulo To: freebsd-acpi@freebsd.org Message-ID: <20080405113631.GA868@fnop.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: njl@freebsd.org Subject: acpi_cpu.c validation of _CST package 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, 05 Apr 2008 11:36:45 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, The attached patch adds a missing functionality to acpi_cpu.c regarding to the revalidation of the _CST package when the notify handler is called. This is needed, for example, in Apple MacBooks: AC plugged in: % sysctl dev.cpu.{0,1}.cx_supported dev.cpu.0.cx_supported: C1/1 C2/1 dev.cpu.1.cx_supported: C1/1 C2/1 AC plugged out: % sysctl dev.cpu.{0,1}.cx_supported dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 dev.cpu.1.cx_supported: C1/1 C2/1 C3/57 I'm not sure if this is the best way to do it and I have doubts about the locking. Comments? -- Rui Paulo --k+w/mQv8wyuph6w0-- From owner-freebsd-acpi@FreeBSD.ORG Sat Apr 5 12:06:44 2008 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 7E2051065670 for ; Sat, 5 Apr 2008 12:06:44 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id EDD178FC24 for ; Sat, 5 Apr 2008 12:06:43 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so572239fgg.35 for ; Sat, 05 Apr 2008 05:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=1oAGvM1IZx7R50o3+KEK12Ry0cl3YDnH4bcCY0aJrKY=; b=no+w54m66FzKSKODKbd0sDNX5HHZpe3leyY5WmhOX1K2LG5ybDAnWugNm84ccKMc9hQethjxU9vwuK5SqhDxwaHhTGwYswPZx77konWOe4aBCD9kFdwYk2Kfm/BAFWTIujkr1kcWpGVR0AUDvDb1udohESdiJYXuYUdzBGhQFhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=HXuo8L5L0p2reah+UqzwVoUcmBcsgmbgTYxUNTcD9BQiaobqoNEgRBRp+uiPvN5W8eQtDkCTynXR3K/Iek693xMQ1+D4BIzFpsOORiItr49elweoGc4E7QG2C7kl4lNIxy1c8FjzZPdkXZdiIkGtY4DdmfM6/GzF/WlD47JFIi4= Received: by 10.82.153.12 with SMTP id a12mr787264bue.47.1207397202309; Sat, 05 Apr 2008 05:06:42 -0700 (PDT) Received: from fnop.net ( [89.214.237.179]) by mx.google.com with ESMTPS id c28sm9402193fka.0.2008.04.05.05.06.39 (version=SSLv3 cipher=OTHER); Sat, 05 Apr 2008 05:06:41 -0700 (PDT) Date: Sat, 5 Apr 2008 13:06:28 +0100 From: Rui Paulo To: freebsd-acpi@freebsd.org, njl@freebsd.org Message-ID: <20080405120628.GA1650@fnop.net> References: <20080405113631.GA868@fnop.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080405113631.GA868@fnop.net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: Subject: Re: acpi_cpu.c validation of _CST package 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, 05 Apr 2008 12:06:44 -0000 Seems like the attachment was stripped for some reason... Index: acpi_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.71 diff -u -p -r1.71 acpi_cpu.c --- acpi_cpu.c 9 Mar 2008 11:19:03 -0000 1.71 +++ acpi_cpu.c 5 Apr 2008 11:20:24 -0000 @@ -157,6 +157,7 @@ static void acpi_cpu_generic_cx_probe(st static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc); static void acpi_cpu_startup(void *arg); static void acpi_cpu_startup_cx(struct acpi_cpu_softc *sc); +static void acpi_cpu_cx_list(struct acpi_cpu_softc *sc); static void acpi_cpu_idle(void); static void acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context); static int acpi_cpu_quirks(void); @@ -801,7 +802,7 @@ acpi_cpu_startup(void *arg) } static void -acpi_cpu_startup_cx(struct acpi_cpu_softc *sc) +acpi_cpu_cx_list(struct acpi_cpu_softc *sc) { struct sbuf sb; int i; @@ -819,7 +820,13 @@ acpi_cpu_startup_cx(struct acpi_cpu_soft } sbuf_trim(&sb); sbuf_finish(&sb); +} +static void +acpi_cpu_startup_cx(struct acpi_cpu_softc *sc) +{ + acpi_cpu_cx_list(sc); + SYSCTL_ADD_STRING(&sc->cpu_sysctl_ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(sc->cpu_dev)), OID_AUTO, "cx_supported", CTLFLAG_RD, @@ -998,12 +1005,25 @@ static void acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context) { struct acpi_cpu_softc *sc = (struct acpi_cpu_softc *)context; - + struct acpi_cpu_softc *isc; + int i; + if (notify != ACPI_NOTIFY_CX_STATES) return; - device_printf(sc->cpu_dev, "Cx states changed\n"); - /* acpi_cpu_cx_cst(sc); */ + /* Update the list of Cx states. */ + acpi_cpu_cx_cst(sc); + acpi_cpu_cx_list(sc); + + /* Update the new lowest useable Cx state for all CPUs. */ + ACPI_SERIAL_BEGIN(cpu); + cpu_cx_count = 0; + for (i = 0; i < cpu_ndevices; i++) { + isc = device_get_softc(cpu_devices[i]); + if (isc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = isc->cpu_cx_count; + } + ACPI_SERIAL_END(cpu); } static int -- Rui Paulo