From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 5 07:14:52 2012 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 0D2F8106566C for ; Sun, 5 Aug 2012 07:14:52 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7D048FC0C for ; Sun, 5 Aug 2012 07:14:51 +0000 (UTC) Received: by vbmv11 with SMTP id v11so575831vbm.13 for ; Sun, 05 Aug 2012 00:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=uJnj0p1VTlnGyzhd5Z9zDjMwr4VWWs9p0jURl13t8vQ=; b=QgrXhGxX9P0YsDxDdersnjuyIU3Lgo0phm5oo8Byh0rrqeIcw/QF5p34IjvH/xUkwD kiqs+CX6R47cQOD2sGysQfaVidyNF5+1D/Kh0JxG0rGjBYsne68MNQn2XI6ZYdRJe7Q5 YWnmvQJxDZvJ++To3ST6uWI7bdbXheLn95r5sKA2TZ0DXFzUKG0yaBxnnpmVx8jPqmZI lT1v+Gf7BY+xICdiPJBRPOzEpXO7SNBB7gDn/7J5CNnpDAyoV9DRNqDiliuBjT+tBDNb 6Pr/8geC5EQ4WVxBk3wuU5En27J9AbqUpvI/MXR8ZhhC7DmA683HEKZDeyqzkxXO9aRl gJbg== Received: by 10.59.8.37 with SMTP id dh5mr6115685ved.2.1344150883880; Sun, 05 Aug 2012 00:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.231.199 with HTTP; Sun, 5 Aug 2012 00:14:03 -0700 (PDT) In-Reply-To: <501DA226.8000707@gmail.com> References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> <501DA226.8000707@gmail.com> From: =?UTF-8?B?5LmU5qWa?= Date: Sun, 5 Aug 2012 15:14:03 +0800 Message-ID: To: matt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi Subject: Re: Resume failed after Suspend on Thinkpad x201i 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: Sun, 05 Aug 2012 07:14:52 -0000 2012/8/5 matt : > On 08/03/12 23:39, =E4=B9=94=E6=A5=9A wrote: >> >> 2012/8/3 Zack Breckenridge : >>> >>> First of all, let me note that the Kernel config file I posted was for >>> 10.0-CURRENT (a few weeks back now though). >>> >>> I've been looking into it, but still haven't developed a patch yet. I >>> have verified that the screen blanking issue, on my hardware, occurs >>> somewhere in the vm86 mode emulation code (which is how VESA is >>> implemented on amd64), ultimately called by vesa_bios_post(), which is >>> called in turn by vesa_load_state() on resume [see: >>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3D3#L1497]. >>> vesa_bios_post() ultimately calls x86bios_call() [see: >>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=3D10#L584] >>> and emulates the real mode VESA "initialization" code with a call to >>> x86emu_exec_call(). >>> >>> I think in order to figure out whats going on from here I will have to >>> do some DDB scripting and capture the output. I don't believe remote >>> debugging will be possible with my hardware (no serial, no >>> firewire)... Anyway, I'm working on it. >>> >>> So to verify that we are having the same issue, you can take the >>> following steps: >>> >>> 1) build a kernel with debugging and VESA enabled: >>> options VESA >>> options KDB >>> options DDB >>> 2) disable X, boot into the console and issue the following commands: >>> # sysctl debug.acpi.suspend_bounce=3D1 >>> # sysctl debug.kdb.enter=3D1 >>> db> break x86emu_exec_call >>> db> c >>> # zzz >>> [you should hit the breakpoint] >>> db> bt >>> x86emu_exec_call() ... >>> vesa_bios_post() ... >>> ... rest of backtrace ... >>> db> c >>> 3) after hitting that last c, your screen should go black. Then you >>> should be able to type "reboot" and reboot cleanly >> >> My screen go black, but type "reboot" no effect. I can be sure to type >> "reboot" and return. >> LED status: >> 1. Disk LED is light, and off at a moment. >> 2. "Z" LED is light, Battary and power LED is light. >> 3. Wifi LED is light. >> >>> I'm pretty sure that if you get the same results, we are having the >>> same issue, though I can make no guarantees. >>> >>> >> When I shutdown from KDE, or type shutdown -p now from console, my >> laptor can't shutdown complete. >> The battary LED is light alawys, others LED is off, and vents of the >> laptor has been blowing hot air. >> _______________________________________________ >> 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" >> > Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a > adaptive -b adaptive" as root and wait 5 minutes to see if the hot air > stops. If it works, try "man powerd" for installation instructions. Lenov= o > laptops are thermally designed for low CPU utilization. I can almost boil > water on mine during buildworld. Without powerd, they run at full thermal > profile and act as excellent hand warmers. > > Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc > slot? Although hard to find you may be able to find a firewire card for > that. Not sure if that would work or not...same goes for a USB->Serial > console, my guess is that it wouldn't work? > > Matt Regarding powerd: I know powerd. I also set it autostart in rc.conf: powerd_enable=3D"YES" powerd_flags=3D"-a adaptive -b adaptive" And I know that sysctl named dev.cpu.0.freq will change between 333 to 2333 with system load. But, When I shutdown the system, the battery indicator finally closed, the fan also continue to operate; Because the fan is in operation, and blow hot air, indicating that the CPU does not really stop working. So my system did not really close.If I do not press the power button to force shut down the power supply, the battery LED is always on, whether connected to AC power. If I accidentally put it in a laptor bag, he will become hot. Regarding extend slot: Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot. I also think that a USB =3D> serial can not be with the remote debugging. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 6 11:07:03 2012 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 44A311065688 for ; Mon, 6 Aug 2012 11:07:03 +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 1540A8FC1B for ; Mon, 6 Aug 2012 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q76B72J1021671 for ; Mon, 6 Aug 2012 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q76B72OT021669 for freebsd-acpi@FreeBSD.org; Mon, 6 Aug 2012 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Aug 2012 11:07:02 GMT Message-Id: <201208061107.q76B72OT021669@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, 06 Aug 2012 11:07:03 -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/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa 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/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject 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 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 p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 6 15:44:45 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81B021065672 for ; Mon, 6 Aug 2012 15:44:45 +0000 (UTC) (envelope-from zbrdge@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id DECB18FC15 for ; Mon, 6 Aug 2012 15:44:44 +0000 (UTC) Received: by laai10 with SMTP id i10so1944745laa.13 for ; Mon, 06 Aug 2012 08:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pMXETqVS2NJTrVYSMCd+X5J/OnsAyEqZDnnZIi5kEwo=; b=v7dyS/s0ZjIxJz5UqRWuoew+TYmusLArM9b/Ub2llA2WmalI4fL8g7M+6N67mdb9cz /EkoaDNQt4dYRYTUh/783dPX8HbC2AVC0D6SaLkQ831obPTkXUz+07ld2xmD0jUnYYx+ 57wZ+bsOZaoUFfVGw/AyrpyoiOi8UHw4H8C7jEPj/XAVw8C2604GLUqruSsTJjy5yCG/ hXYM7PgT2Oi2zjPGzs3M+NZYR7budHjy9YkKtIFKx6tsX5mSZ9iZGWX1b5SdOnOYE+JO dSaxBZ3L5Uy/XOAF3biSCxEnqKHrz9/25bkqlUN6B+V7YIv0y3Xw17s5n/+AXxL3DT1J eVfg== MIME-Version: 1.0 Received: by 10.112.17.227 with SMTP id r3mr4787386lbd.41.1344267883241; Mon, 06 Aug 2012 08:44:43 -0700 (PDT) Received: by 10.112.41.131 with HTTP; Mon, 6 Aug 2012 08:44:43 -0700 (PDT) In-Reply-To: References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> <501DA226.8000707@gmail.com> Date: Mon, 6 Aug 2012 08:44:43 -0700 Message-ID: From: Zack Breckenridge To: =?UTF-8?B?5LmU5qWa?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi Subject: Re: Resume failed after Suspend on Thinkpad x201i 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, 06 Aug 2012 15:44:45 -0000 At this point, after having simply read through the sources and done some research, it looks like remote debugging might not be necessary, or even very useful, in this case after all (though it would be nice to have for future debugging endeavors so I will look into your suggestions, thank you). So once again, on my hardware and probably Honest Qiao's as well, the call the vesa_bios_post() on resume really boils down to: x86bios_call(®s, X86BIOS_PHYSTOSEG(vesa_bios_offs + 3), X86BIOS_PHYSTOOFF(vesa_bios_offs + 3)); I think this is used to "normalize" the graphics card state [see: http://fxr.watson.org/fxr/source/dev/fb/vesa.c#L1506], before using VBE (real mode) state restore code to restore the state of the graphics device. All it's doing is executing the POST code in the VESA option ROM, copied to 0xc0000 by the BIOS (and this is an old "legacy" boot method, apparently. UEFI BIOSes support this for "backward compatibility"). So there's real mode code at this location and the x86emu library is used to execute it, etc. This call is what is causing my screen to "blank". However, it is also what is causing my display to power on after a resume. If I comment out the call to vesa_bios_post() in vesa_load_state(), then set debug.acpi.suspend_bounce=3D1 and go S3, everything just works. The screen even flashes when the VESA state restore code is executed and I can use the VESA driver as usual - for example I can change the video mode with "vidcontrol MODE_280". But if I actually let the machine power down, on resume the display never powers back on. I was hoping I could use the VESA DPMS driver to power it back on and everything would just work (though this would still be a temporary hack). So I'm looking for a general way of powering on the display after resume that works for everyone. Obviously this code worked for the original developer(s) hardware and may work well for a set of hardware out there. One line of inquiry I'm following is how i915kms powers the device on after a resume - because it does and works just fine. Zack On Sun, Aug 5, 2012 at 12:14 AM, =C7=C7=B3=FE wrote: > 2012/8/5 matt : >> On 08/03/12 23:39, =C7=C7=B3=FE wrote: >>> >>> 2012/8/3 Zack Breckenridge : >>>> >>>> First of all, let me note that the Kernel config file I posted was for >>>> 10.0-CURRENT (a few weeks back now though). >>>> >>>> I've been looking into it, but still haven't developed a patch yet. I >>>> have verified that the screen blanking issue, on my hardware, occurs >>>> somewhere in the vm86 mode emulation code (which is how VESA is >>>> implemented on amd64), ultimately called by vesa_bios_post(), which is >>>> called in turn by vesa_load_state() on resume [see: >>>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3D3#L1497]. >>>> vesa_bios_post() ultimately calls x86bios_call() [see: >>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=3D10#L584= ] >>>> and emulates the real mode VESA "initialization" code with a call to >>>> x86emu_exec_call(). >>>> >>>> I think in order to figure out whats going on from here I will have to >>>> do some DDB scripting and capture the output. I don't believe remote >>>> debugging will be possible with my hardware (no serial, no >>>> firewire)... Anyway, I'm working on it. >>>> >>>> So to verify that we are having the same issue, you can take the >>>> following steps: >>>> >>>> 1) build a kernel with debugging and VESA enabled: >>>> options VESA >>>> options KDB >>>> options DDB >>>> 2) disable X, boot into the console and issue the following commands: >>>> # sysctl debug.acpi.suspend_bounce=3D1 >>>> # sysctl debug.kdb.enter=3D1 >>>> db> break x86emu_exec_call >>>> db> c >>>> # zzz >>>> [you should hit the breakpoint] >>>> db> bt >>>> x86emu_exec_call() ... >>>> vesa_bios_post() ... >>>> ... rest of backtrace ... >>>> db> c >>>> 3) after hitting that last c, your screen should go black. Then you >>>> should be able to type "reboot" and reboot cleanly >>> >>> My screen go black, but type "reboot" no effect. I can be sure to type >>> "reboot" and return. >>> LED status: >>> 1. Disk LED is light, and off at a moment. >>> 2. "Z" LED is light, Battary and power LED is light. >>> 3. Wifi LED is light. >>> >>>> I'm pretty sure that if you get the same results, we are having the >>>> same issue, though I can make no guarantees. >>>> >>>> >>> When I shutdown from KDE, or type shutdown -p now from console, my >>> laptor can't shutdown complete. >>> The battary LED is light alawys, others LED is off, and vents of the >>> laptor has been blowing hot air. >>> _______________________________________________ >>> 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" >>> >> Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a >> adaptive -b adaptive" as root and wait 5 minutes to see if the hot air >> stops. If it works, try "man powerd" for installation instructions. Leno= vo >> laptops are thermally designed for low CPU utilization. I can almost boi= l >> water on mine during buildworld. Without powerd, they run at full therma= l >> profile and act as excellent hand warmers. >> >> Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc >> slot? Although hard to find you may be able to find a firewire card for >> that. Not sure if that would work or not...same goes for a USB->Serial >> console, my guess is that it wouldn't work? >> >> Matt > > Regarding powerd: > I know powerd. > I also set it autostart in rc.conf: > powerd_enable=3D"YES" > powerd_flags=3D"-a adaptive -b adaptive" > And I know that sysctl named dev.cpu.0.freq will change between 333 to > 2333 with system load. > > But, When I shutdown the system, the battery indicator finally closed, > the fan also continue to operate; > Because the fan is in operation, and blow hot air, indicating that the > CPU does not really stop working. > > So my system did not really close.If I do not press the power button > to force shut down the power supply, the battery LED is always on, > whether connected to AC power. > If I accidentally put it in a laptor bag, he will become hot. > > > Regarding extend slot: > Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot. > I also think that a USB =3D> serial can not be with the remote debugging. From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 7 18:44:22 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 731FB106564A; Tue, 7 Aug 2012 18:44:22 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 204238FC1D; Tue, 7 Aug 2012 18:44:21 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q77IhImi027522; Tue, 7 Aug 2012 11:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1344364999; bh=p+8ScgOe8NRhqsB4iE4U8G+eGUiZFXZCbOi+rSOSOW0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=C38ru8/JO7DsQs8MV/f/890+NQHtV2Zj2Ev/vy59pNXv2FdsvtMcd94HqBV46bJxG VV4pLtMQWEqRKQLtrmH4x/ORest8GEk8OIQWxmNzCf5BuW6BvJ6zqPdejm5L/599cl VhUGGEYZaIWORgNuaY6SUd9yX6UKyanQ+N3vf0h8= From: Sean Bruno To: John Baldwin In-Reply-To: <1343751187.2957.4.camel@powernoodle.corp.yahoo.com> References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <201207300807.20225.jhb@freebsd.org> <1343751187.2957.4.camel@powernoodle.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 07 Aug 2012 11:43:17 -0700 Message-ID: <1344364997.18854.9.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 364998002 Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? 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, 07 Aug 2012 18:44:22 -0000 On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > I am currently running with a value of 128 and doing a bit of > > testing. > > > > I think it should be something like MAX(32, MAXCPU). > > Ah, that sounds WAY more reasonable. I shall test thusly. > > Sean > This did *not* work on a dual socket machine with MAXCPU at 64. Amusing. sean From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 7 21:33:05 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DF821065670; Tue, 7 Aug 2012 21:33:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E68C38FC0A; Tue, 7 Aug 2012 21:33:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 36895B949; Tue, 7 Aug 2012 17:33:04 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Tue, 7 Aug 2012 17:30:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <1343751187.2957.4.camel@powernoodle.corp.yahoo.com> <1344364997.18854.9.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1344364997.18854.9.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208071730.52899.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 Aug 2012 17:33:04 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? 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, 07 Aug 2012 21:33:05 -0000 On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote: > On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > > I am currently running with a value of 128 and doing a bit of > > > testing. > > > > > > I think it should be something like MAX(32, MAXCPU). > > > > Ah, that sounds WAY more reasonable. I shall test thusly. > > > > Sean > > > > This did *not* work on a dual socket machine with MAXCPU at 64. Hmm, can you find out how many tasks it wanted? I know part of it is a function of the number of CPUs (we queue a task for each CPU at one point before tasks are running). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 7 23:31:54 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AA3B106566B; Tue, 7 Aug 2012 23:31:54 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id B68C58FC0A; Tue, 7 Aug 2012 23:31:53 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q77NV9sT034479; Tue, 7 Aug 2012 16:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1344382270; bh=ZIoE+w5alfZxVYJ9sRhQfEtqFfqK/OqLejlQMR4lkH0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=XOszc/e895NkCQndHRBJO3hkZXQS25IxQ0h3hq/DKpHZFJZQ7Zt60gnxVqD6adn3P xe3v6mX7mfuOChhJ5P8hQBrhL+K07EiB+W5R++5QMqHswIYkU6odxxkk4o5XUS/ZXe PcucydLinJY8QKPMW/PuDTIlAkJ7KgKwaxDcLdNQ= From: Sean Bruno To: John Baldwin In-Reply-To: <201208071730.52899.jhb@freebsd.org> References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <1343751187.2957.4.camel@powernoodle.corp.yahoo.com> <1344364997.18854.9.camel@powernoodle.corp.yahoo.com> <201208071730.52899.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 07 Aug 2012 16:31:09 -0700 Message-ID: <1344382269.18854.22.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 382269003 Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? 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, 07 Aug 2012 23:31:54 -0000 On Tue, 2012-08-07 at 14:30 -0700, John Baldwin wrote: > On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote: > > On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > > > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > > > I am currently running with a value of 128 and doing a bit of > > > > testing. > > > > > > > > I think it should be something like MAX(32, MAXCPU). > > > > > > Ah, that sounds WAY more reasonable. I shall test thusly. > > > > > > Sean > > > > > > > This did *not* work on a dual socket machine with MAXCPU at 64. > > Hmm, can you find out how many tasks it wanted? I know part of > it is a function of the number of CPUs (we queue a task for each > CPU at one point before tasks are running). > I extended the log message in acpi_task enqueue() with the current task count, max task setting and max thread setting when the error occurs. It appears that we are definitely going above max tasks from my review: AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable acpi_task_count(64), acpi_max_tasks(64) max_threads(3) I don't see any evidence that the log message in acpi_taskq_init() is firing at any point. "if (acpi_task_count > 0) ..." Sean From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 8 11:27:48 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BBBD106566C; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED138FC0A; Wed, 8 Aug 2012 11:27:47 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9F63DB945; Wed, 8 Aug 2012 07:27:46 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Wed, 8 Aug 2012 07:25:23 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <201208071730.52899.jhb@freebsd.org> <1344382269.18854.22.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1344382269.18854.22.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208080725.24199.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Aug 2012 07:27:46 -0400 (EDT) Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? 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, 08 Aug 2012 11:27:48 -0000 On Tuesday, August 07, 2012 07:31:09 PM Sean Bruno wrote: > On Tue, 2012-08-07 at 14:30 -0700, John Baldwin wrote: > > On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote: > > > On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > > > > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > > > > I am currently running with a value of 128 and doing a bit of > > > > > > > > > > testing. > > > > > > > > > > I think it should be something like MAX(32, MAXCPU). > > > > > > > > Ah, that sounds WAY more reasonable. I shall test thusly. > > > > > > > > Sean > > > > > > This did *not* work on a dual socket machine with MAXCPU at 64. > > > > Hmm, can you find out how many tasks it wanted? I know part of > > it is a function of the number of CPUs (we queue a task for each > > CPU at one point before tasks are running). > > I extended the log message in acpi_task enqueue() with the current task > count, max task setting and max thread setting when the error occurs. > It appears that we are definitely going above max tasks from my review: > > AcpiOsExecute: failed to enqueue task, consider increasing the > debug.acpi.max_tasks tunable acpi_task_count(64), acpi_max_tasks(64) > max_threads(3) I meant that with the limit jacked up to something that silences the warning (such as 128), what is the max number of tasks queued? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 8 17:01:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCF26106564A; Wed, 8 Aug 2012 17:01:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 6E61D8FC08; Wed, 8 Aug 2012 17:01:21 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q78GxN9X002848; Wed, 8 Aug 2012 09:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1344445164; bh=IXeRwpXJ8nXsiD70OJyKaNi/Zy0xwoppfVLOx5qqSfo=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=L8cAik9Awp/q39g0SkJ3U5AfEFODI3PC+LLXR+OUxh9sWxxfyOJ1TMhO2W8IVMLB3 Qo66evdE428BpS9PcZtbYZxFNdq2PlfqxvtUdYne049pRYees8VuO4KX/uNZhHxg4k cU4eAvsH5OjM927jSVFSv6krvwtfWDUyTKPP3fDA= From: Sean Bruno To: John Baldwin In-Reply-To: <201208080725.24199.jhb@freebsd.org> References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <201208071730.52899.jhb@freebsd.org> <1344382269.18854.22.camel@powernoodle.corp.yahoo.com> <201208080725.24199.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Aug 2012 09:59:23 -0700 Message-ID: <1344445163.2813.2.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 445163000 Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? 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, 08 Aug 2012 17:01:21 -0000 On Wed, 2012-08-08 at 04:25 -0700, John Baldwin wrote: > I meant that with the limit jacked up to something that silences the > warning > (such as 128), what is the max number of tasks queued? > > I set debug.acpi.max_tasks=128 and added a temp log message to acpi_task_enqueue(). I see the system request *98* tasks according to my test on this new Dell box. Is it possible that the queue really isn't running yet or something? AcpiOsExecute: acpi_task_count(98), acpi_max_tasks(128) max_threads(3) code modified to generate log message: for (at = NULL, i = 0; i < acpi_max_tasks; i++) if (atomic_cmpset_int(&acpi_tasks[i].at_flag, ACPI_TASK_FREE, ACPI_TASK_USED)) { at = &acpi_tasks[i]; acpi_task_count++; if (acpi_task_count > 63) printf("AcpiOsExecute: acpi_task_count(%d), acpi_max_tasks(%d) max_threads(%d)\n", acpi_task_count, acpi_max_tasks, acpi_max_threads); break; } From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 8 17:23:40 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CC811065676; Wed, 8 Aug 2012 17:23:40 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id E64E88FC0C; Wed, 8 Aug 2012 17:23:39 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 08 Aug 2012 10:23:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.77,733,1336374000"; d="scan'208";a="131642531" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by AZSMGA002.ch.intel.com with ESMTP; 08 Aug 2012 10:23:38 -0700 Received: from orsmsx104.amr.corp.intel.com (10.22.225.131) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 8 Aug 2012 10:23:37 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.106]) by ORSMSX104.amr.corp.intel.com ([169.254.3.210]) with mapi id 14.01.0355.002; Wed, 8 Aug 2012 10:23:37 -0700 From: "Moore, Robert" To: Sean Bruno , John Baldwin Thread-Topic: Time to increase MAX_TASKS? Thread-Index: AQHNbn5wQ0ggCOY5J0Ws2tj0ZcHWnJdEBxmAgAsqR4CAAC7SAIAAIZyAgADHjoCAAF1RgP//kO8w Date: Wed, 8 Aug 2012 17:23:36 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E346B49703@ORSMSX101.amr.corp.intel.com> References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <201208071730.52899.jhb@freebsd.org> <1344382269.18854.22.camel@powernoodle.corp.yahoo.com> <201208080725.24199.jhb@freebsd.org> <1344445163.2813.2.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1344445163.2813.2.camel@powernoodle.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" Subject: RE: Time to increase MAX_TASKS? 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, 08 Aug 2012 17:23:40 -0000 SnVzdCBGWUksIHdlJ3ZlIHNlZW4gdGhlIEFjcGlPc0V4ZWN1dGUgdGFzayBRIGdldCB2ZXJ5IGxh cmdlIGlmDQpUaGVyZSBpcyBhIEdQRSBmbG9vZCB0aGF0IHJlc3VsdHMgaW4gbWFueSwgbWFueSBu b3RpZnkgb3BlcmF0aW9ucy4NCg0KQW5kIGluIHRoZXNlIGNhc2VzLCBpdCB3YXMgYWx3YXlzIHJl bGF0ZWQgdG8gdGhlIEVDIChFbWJlZGRlZCBDb250cm9sbGVyKS4NCg0KQm9iDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1mcmVlYnNkLWFjcGlAZnJlZWJz ZC5vcmcgW21haWx0bzpvd25lci1mcmVlYnNkLQ0KPiBhY3BpQGZyZWVic2Qub3JnXSBPbiBCZWhh bGYgT2YgU2VhbiBCcnVubw0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwOCwgMjAxMiA5OjU5 IEFNDQo+IFRvOiBKb2huIEJhbGR3aW4NCj4gQ2M6IGZyZWVic2QtYWNwaUBmcmVlYnNkLm9yZw0K PiBTdWJqZWN0OiBSZTogVGltZSB0byBpbmNyZWFzZSBNQVhfVEFTS1M/DQo+IA0KPiBPbiBXZWQs IDIwMTItMDgtMDggYXQgMDQ6MjUgLTA3MDAsIEpvaG4gQmFsZHdpbiB3cm90ZToNCj4gPiBJIG1l YW50IHRoYXQgd2l0aCB0aGUgbGltaXQgamFja2VkIHVwIHRvIHNvbWV0aGluZyB0aGF0IHNpbGVu Y2VzIHRoZQ0KPiA+IHdhcm5pbmcgKHN1Y2ggYXMgMTI4KSwgd2hhdCBpcyB0aGUgbWF4IG51bWJl ciBvZiB0YXNrcyBxdWV1ZWQ/DQo+ID4NCj4gPg0KPiANCj4gSSBzZXQgZGVidWcuYWNwaS5tYXhf dGFza3M9MTI4IGFuZCBhZGRlZCBhIHRlbXAgbG9nIG1lc3NhZ2UgdG8NCj4gYWNwaV90YXNrX2Vu cXVldWUoKS4gIEkgc2VlIHRoZSBzeXN0ZW0gcmVxdWVzdCAqOTgqIHRhc2tzIGFjY29yZGluZyB0 bw0KPiBteSB0ZXN0IG9uIHRoaXMgbmV3IERlbGwgYm94LiAgSXMgaXQgcG9zc2libGUgdGhhdCB0 aGUgcXVldWUgcmVhbGx5DQo+IGlzbid0IHJ1bm5pbmcgeWV0IG9yIHNvbWV0aGluZz8NCj4gDQo+ IDxzbmlwPg0KPiBBY3BpT3NFeGVjdXRlOiBhY3BpX3Rhc2tfY291bnQoOTgpLCBhY3BpX21heF90 YXNrcygxMjgpIG1heF90aHJlYWRzKDMpDQo+IDxzbmlwPg0KPiANCj4gDQo+IGNvZGUgbW9kaWZp ZWQgdG8gZ2VuZXJhdGUgbG9nIG1lc3NhZ2U6DQo+IA0KPiAgICAgZm9yIChhdCA9IE5VTEwsIGkg PSAwOyBpIDwgYWNwaV9tYXhfdGFza3M7IGkrKykNCj4gICAgICAgICBpZiAoYXRvbWljX2NtcHNl dF9pbnQoJmFjcGlfdGFza3NbaV0uYXRfZmxhZywgQUNQSV9UQVNLX0ZSRUUsDQo+ICAgICAgICAg ICAgIEFDUElfVEFTS19VU0VEKSkgew0KPiAgICAgICAgICAgICBhdCA9ICZhY3BpX3Rhc2tzW2ld Ow0KPiAgICAgICAgICAgICBhY3BpX3Rhc2tfY291bnQrKzsNCj4gICAgICAgICAgICAgaWYgKGFj cGlfdGFza19jb3VudCA+IDYzKQ0KPiAgICAgICAgICAgICAgICAgcHJpbnRmKCJBY3BpT3NFeGVj dXRlOiBhY3BpX3Rhc2tfY291bnQoJWQpLA0KPiBhY3BpX21heF90YXNrcyglZCkgbWF4X3RocmVh ZHMoJWQpXG4iLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBhY3BpX3Rhc2tfY291bnQsIGFj cGlfbWF4X3Rhc2tzLA0KPiBhY3BpX21heF90aHJlYWRzKTsNCj4gICAgICAgICAgICAgYnJlYWs7 DQo+ICAgICAgICAgfQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gZnJlZWJzZC1hY3BpQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBo dHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFjcGkNCj4g VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYWNwaS11bnN1YnNjcmli ZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 9 02:06:44 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF39B106566C for ; Thu, 9 Aug 2012 02:06:44 +0000 (UTC) (envelope-from info@minesold.com.au) Received: from node-sl1915.smtp.com (node-sl1915.smtp.com [50.23.172.155]) by mx1.freebsd.org (Postfix) with ESMTP id 96ECF8FC18 for ; Thu, 9 Aug 2012 02:06:44 +0000 (UTC) Received: from UserHPBelkin (CPE-121-222-183-32.lnse1.woo.bigpond.net.au [121.222.183.32]) by node-sl1915.smtp.com (Postfix) with ESMTPA id 3DE783828A1A for ; Wed, 8 Aug 2012 22:06:40 -0400 (EDT) X-SMTPCOM-Spam-Policy: SendBlaster SMTP is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Sender-ID: 444448 X-SMTPCOM-Tracking-Number: 495556063 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtp.com; s=smtpcomcustomers; t=1344478004; bh=1C28e7BQVqEADmhh3FOZcMlXhgE3TfJRnT4s4NX9S48=; h=MIME-Version:From:Reply-To:To:Subject:Content-Type:X-Mailer:Date: Message-ID; b=c9/n1OwApru/aSxZlD0Utjsp2Pn5WCRVFqLArh4TNXWymkm77gYpCEInnUHq07XVM WEwOgHPW1Yz40MF3934abIpCw7ziBTnKyp2TXkZHT28uqu2WJG8dB4Eg+PSzFFFQLV jrLufW6DB5+yXg0e2bsioobgy7l65xr7V1qjLi2k= MIME-Version: 1.0 From: "Mine Sold" To: freebsd-acpi@freebsd.org Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_001_5663_00350403.603C1257" X-Mailer: SmartSend.2.0.127 Date: Thu, 9 Aug 2012 12:06:41 +1000 Message-ID: <56963866837682832627909@User-HP> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Showcase Your Business to the Mining Industry X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@minesold.com.au List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:06:44 -0000 ------=_NextPart_001_5663_00350403.603C1257 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U0hPV0NBU0UgWU9VUiBCVVNJTkVTUyBTRVJWSUNFUyAmIFBST0RVQ1RTIFRPIFRIT1VTQU5EUyAN Cg0KIA0KDQpJZiB5b3UgYXJlIGxvb2tpbmcgdG8gaW5jcmVhc2UgeW91ciBjdXN0b21lciBiYXNl LCB0aGluayCTb3V0c2lkZSB0aGUgc3F1YXJllC4NCg0KIA0KDQpIYXZlIHlvdXIgYnVzaW5lc3Mg U0hPV0NBU0VEIG9uIEVWRVJZIEFJUkxJTkUgU0VBVCwgRVZFUlkgRkxJR0hULCBFVkVSWSBEQVks IEZvciAzMCBEYXlzIG9yIDYwIERheXMuIGluIGZyb250IG9mIGhpZ2ggaW5jb21lIGVhcm5lcnMs IHdpdGggYSBoaWdoIHBlcmNlbnRhZ2UgaW4gdGhlIE1pbmluZyBJbmR1c3RyeS4NCg0KDQpPdXIg SW5mbGlnaHQgbWFnYXppbmVzIGFyZSB0aGUgb25seSBpbmZsaWdodCBlbnRlcnRhaW5tZW50IGFu ZCBhcmUgcmVhZCBhbmQgcmUtcmVhZC4NCg0KSWYgeW91IG5lZWQgdG8gYWR2ZXJ0aXNlIHRvIHBv dGVudGlhbCBjdXN0b21lcnMgd2hvIGhhdmUgdGhlIGRpc3Bvc2FibGUgaW5jb21lLCBkb24ndCBs ZXQgdGhpcyBvcHBvcnR1bml0eSBwYXNzIHlvdSBieS4NCg0KRE9OklQgTUlTUyBZT1VSIEZMSUdI VC4gDQoNCldlIGFyZSBUYWtpbmcgQm9va2luZ3Mgbm93IGZvciB0aGlzIE5leHQgSXNzdWUNCg0K Q2FsbCBub3cgdG8gUmVzZXJ2ZSBZb3VyIFNwb3QuDQoNCkNhbGwgU3R1YXJ0IExvdmVsbCBOT1cg MDQwNyA3MjAgOTMwDQoNCnZpc2l0IG91ciB3ZWJzaXRlIGF0IHd3dy5taW5lc29sZC5jb20uYXUN Cg0KRW1haWwgYSByZXF1ZXN0IGZvciBtb3JlIGluZm9ybWF0aW9uIGluZm9AbWluZXNvbGQuY29t LmF1DQoNCk1pbmVzIFNvbGQuLi4uLi4gSGFzIFlvdXJzID8NCg0KDQpVbnN1YnNjcmliZSBmcm9t IHRoaXMgbWFpbGluZyBsaXN0DQoNCg0KIA0KDQo= ------=_NextPart_001_5663_00350403.603C1257-- From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 10 16:54:21 2012 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 C37241065673 for ; Fri, 10 Aug 2012 16:54:21 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD188FC17 for ; Fri, 10 Aug 2012 16:54:21 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1308432qcs.13 for ; Fri, 10 Aug 2012 09:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/jkFWKoYLIn7OY1uLavxHD3a0TSXEWuUsbpLwtd55yI=; b=hSGmEPuWwBA7711hp1bK359HkU5i+bF3MVDHwUa+hH3yOMF/f/CiAh3GRgPV0BXw4z 6aHArRLoxFIHobMmwMDDGpiYSEMnaEAv2T9B2+0C/sr0+2c1qfdjmdEjqagM1M/UcgeS 3EnA7An+ODln0jJepFnBjBpl/prVK/8WBJKYbUgB07I22efo/8TX4PBzUtUq4+Rau3nU 1/ZRhAfs9kRnVLV2eiY+3GFbwHm+qI4sken4TwCytva5UHqsDG1sd1QpMfJe3tkXmlB/ qnyaX0XW39Q9oDxAIFukpjqDejQ+qcvd8rCaaXfCrvOBoPvAIdoLSS72UJ7X20OYxvTe OAAA== Received: by 10.224.222.141 with SMTP id ig13mr351719qab.32.1344617660617; Fri, 10 Aug 2012 09:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.224 with HTTP; Fri, 10 Aug 2012 09:53:40 -0700 (PDT) In-Reply-To: References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> <501DA226.8000707@gmail.com> From: =?UTF-8?B?5LmU5qWa?= Date: Sat, 11 Aug 2012 00:53:40 +0800 Message-ID: To: Zack Breckenridge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi Subject: Re: Resume failed after Suspend on Thinkpad x201i 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, 10 Aug 2012 16:54:21 -0000 2012/8/6 Zack Breckenridge : > At this point, after having simply read through the sources and done > some research, it looks like remote debugging might not be necessary, > or even very useful, in this case after all (though it would be nice > to have for future debugging endeavors so I will look into your > suggestions, thank you). > > So once again, on my hardware and probably Honest Qiao's as well, the > call the vesa_bios_post() on resume really boils down to: > > x86bios_call(®s, X86BIOS_PHYSTOSEG(vesa_bios_offs + 3), > X86BIOS_PHYSTOOFF(vesa_bios_offs + 3)); > > I think this is used to "normalize" the graphics card state [see: > http://fxr.watson.org/fxr/source/dev/fb/vesa.c#L1506], before using > VBE (real mode) state restore code to restore the state of the > graphics device. All it's doing is executing the POST code in the VESA > option ROM, copied to 0xc0000 by the BIOS (and this is an old "legacy" > boot method, apparently. UEFI BIOSes support this for "backward > compatibility"). So there's real mode code at this location and the > x86emu library is used to execute it, etc. This call is what is > causing my screen to "blank". However, it is also what is causing my > display to power on after a resume. If I comment out the call to > vesa_bios_post() in vesa_load_state(), then set > debug.acpi.suspend_bounce=3D1 and go S3, everything just works. The > screen even flashes when the VESA state restore code is executed and I > can use the VESA driver as usual - for example I can change the video > mode with "vidcontrol MODE_280". > > But if I actually let the machine power down, on resume the display > never powers back on. I was hoping I could use the VESA DPMS driver to > power it back on and everything would just work (though this would > still be a temporary hack). > > So I'm looking for a general way of powering on the display after > resume that works for everyone. Obviously this code worked for the > original developer(s) hardware and may work well for a set of hardware > out there. One line of inquiry I'm following is how i915kms powers the > device on after a resume - because it does and works just fine. > > Zack > > On Sun, Aug 5, 2012 at 12:14 AM, =E4=B9=94=E6=A5=9A wrote: >> 2012/8/5 matt : >>> On 08/03/12 23:39, =E4=B9=94=E6=A5=9A wrote: >>>> >>>> 2012/8/3 Zack Breckenridge : >>>>> >>>>> First of all, let me note that the Kernel config file I posted was fo= r >>>>> 10.0-CURRENT (a few weeks back now though). >>>>> >>>>> I've been looking into it, but still haven't developed a patch yet. I >>>>> have verified that the screen blanking issue, on my hardware, occurs >>>>> somewhere in the vm86 mode emulation code (which is how VESA is >>>>> implemented on amd64), ultimately called by vesa_bios_post(), which i= s >>>>> called in turn by vesa_load_state() on resume [see: >>>>> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3D3#L1497]. >>>>> vesa_bios_post() ultimately calls x86bios_call() [see: >>>>> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=3D10#L58= 4] >>>>> and emulates the real mode VESA "initialization" code with a call to >>>>> x86emu_exec_call(). >>>>> >>>>> I think in order to figure out whats going on from here I will have t= o >>>>> do some DDB scripting and capture the output. I don't believe remote >>>>> debugging will be possible with my hardware (no serial, no >>>>> firewire)... Anyway, I'm working on it. >>>>> >>>>> So to verify that we are having the same issue, you can take the >>>>> following steps: >>>>> >>>>> 1) build a kernel with debugging and VESA enabled: >>>>> options VESA >>>>> options KDB >>>>> options DDB >>>>> 2) disable X, boot into the console and issue the following commands: >>>>> # sysctl debug.acpi.suspend_bounce=3D1 >>>>> # sysctl debug.kdb.enter=3D1 >>>>> db> break x86emu_exec_call >>>>> db> c >>>>> # zzz >>>>> [you should hit the breakpoint] >>>>> db> bt >>>>> x86emu_exec_call() ... >>>>> vesa_bios_post() ... >>>>> ... rest of backtrace ... >>>>> db> c >>>>> 3) after hitting that last c, your screen should go black. Then you >>>>> should be able to type "reboot" and reboot cleanly >>>> >>>> My screen go black, but type "reboot" no effect. I can be sure to type >>>> "reboot" and return. >>>> LED status: >>>> 1. Disk LED is light, and off at a moment. >>>> 2. "Z" LED is light, Battary and power LED is light. >>>> 3. Wifi LED is light. >>>> >>>>> I'm pretty sure that if you get the same results, we are having the >>>>> same issue, though I can make no guarantees. >>>>> >>>>> >>>> When I shutdown from KDE, or type shutdown -p now from console, my >>>> laptor can't shutdown complete. >>>> The battary LED is light alawys, others LED is off, and vents of the >>>> laptor has been blowing hot air. >>>> _______________________________________________ >>>> 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= " >>>> >>> Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a >>> adaptive -b adaptive" as root and wait 5 minutes to see if the hot air >>> stops. If it works, try "man powerd" for installation instructions. Len= ovo >>> laptops are thermally designed for low CPU utilization. I can almost bo= il >>> water on mine during buildworld. Without powerd, they run at full therm= al >>> profile and act as excellent hand warmers. >>> >>> Zack: Regarding remote debugging, do you have an expresscard/cardbus/et= c >>> slot? Although hard to find you may be able to find a firewire card for >>> that. Not sure if that would work or not...same goes for a USB->Serial >>> console, my guess is that it wouldn't work? >>> >>> Matt >> >> Regarding powerd: >> I know powerd. >> I also set it autostart in rc.conf: >> powerd_enable=3D"YES" >> powerd_flags=3D"-a adaptive -b adaptive" >> And I know that sysctl named dev.cpu.0.freq will change between 333 to >> 2333 with system load. >> >> But, When I shutdown the system, the battery indicator finally closed, >> the fan also continue to operate; >> Because the fan is in operation, and blow hot air, indicating that the >> CPU does not really stop working. >> >> So my system did not really close.If I do not press the power button >> to force shut down the power supply, the battery LED is always on, >> whether connected to AC power. >> If I accidentally put it in a laptor bag, he will become hot. >> >> >> Regarding extend slot: >> Lenovo thinkpad x201 only has USB slot. It hasn't Serial slot. >> I also think that a USB =3D> serial can not be with the remote debugging= . Thank you for your hard work. I want to know, is there any way to solve problems that can not be shutdown the system. As I said earlier, command "shutdown -p now" can shutdown the os, but it can not turn off the battery and can not real turn off CPU and fan. This Problem made =E2=80=8B=E2=80=8Bme a headache. Every time I have to hol= d the power button to force shutdown. I'm afraid that when forgotten, will lead to serious consequences.