From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 02:09:53 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A380616C; Sun, 7 Jul 2013 02:09:53 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 519371CBC; Sun, 7 Jul 2013 02:09:52 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r6729kwO045547; Sat, 6 Jul 2013 20:09:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r6729k3q045544; Sat, 6 Jul 2013 20:09:46 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 6 Jul 2013 20:09:46 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130707003651.Y26496@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 06 Jul 2013 20:09:46 -0600 (MDT) Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 02:09:53 -0000 On Sun, 7 Jul 2013, Ian Smith wrote: > So even if cpu_running_mark were 100% (-r100), anything busier than 25% > of our example 75MHz would shift to maximum freq immediately, where the > load will likely plummet to just a few percent, way less than the 25% > (at -r100) needed to keep it at that freq; ie it will most likely hunt. It may do that, but if so it's doing it more quickly than is visible running powerd -a hyper -n hyper -v. > You don't appear to be taking any notice of the -i idle percentage here; > perhaps that would be a more useful shift-down criterion? Even so, with > a full house of frequencies, I can't see this being easy to tune as is. > > Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on? > And your powerd_flags setting? /boot/loader.conf: hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" hw.acpi.cpu.cx_lowest="C3" I've routinely used the first two since first reading about them, I think in another post by Kevin. /etc/rc.conf: powerd_flags="-a hyper -n hyper" performance_cx_lowest="Cmax" performance_cpu_freq="HIGH" That grep provides a lot of unrelated "freq" stuff, so here's a guess at what you want to see: hw.acpi.cpu.cx_lowest: C8 machdep.acpi_timer_freq: 3579545 machdep.i8254_freq: 1193182 machdep.tsc_freq: 3309792585 dev.cpu.0.freq: 3601 dev.cpu.0.freq_levels: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.cpu.0.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 31.99% 64.88% 3.12% last 1203us dev.cpu.1.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_usage: 37.14% 61.17% 1.68% last 11us dev.cpu.2.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.2.cx_lowest: C8 dev.cpu.2.cx_usage: 36.06% 61.83% 2.09% last 3830us dev.cpu.3.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.3.cx_lowest: C8 dev.cpu.3.cx_usage: 36.64% 61.02% 2.32% last 2us dev.est.0.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.1.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.2.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.3.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.cpufreq.2.%driver: cpufreq dev.cpufreq.2.%parent: cpu2 dev.cpufreq.3.%driver: cpufreq dev.cpufreq.3.%parent: cpu3 This is an i5, with the "3601" being turbo mode. From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 05:51:25 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E5410EF4; Sun, 7 Jul 2013 05:51:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 506F211D3; Sun, 7 Jul 2013 05:51:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r675pCpx063057; Sun, 7 Jul 2013 15:51:13 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 7 Jul 2013 15:51:12 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130707154526.O26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 05:51:25 -0000 On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > On 30 June 2013 07:22, Ian Smith wrote: [..] > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > Maybe someone who knows might comment on that? Does noone know what that signifies? Maybe it's not relevant to this. > > Just checking: you've tried other USB devices apart from uftdi0? > > Yup, there's no 5v on the port. I was rather taken aback to hear this. Would not this indicate a failure to reinitialise the basic underlying USB hardware on resume? More than a bit bemused, Ian From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 07:32:56 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 87CF5EBC; Sun, 7 Jul 2013 07:32:56 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF4E1469; Sun, 7 Jul 2013 07:32:55 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 24D177A172; Sun, 7 Jul 2013 09:32:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 084238ED850; Sun, 7 Jul 2013 09:32:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYb+-B2Yc4U0; Sun, 7 Jul 2013 09:32:52 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id C20FE8ED84F; Sun, 7 Jul 2013 09:32:51 +0200 (CEST) Subject: RE: USB ports on Lenovo T400 do not work after a suspend/resume From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Ian_Smith?= , =?utf-8?Q?Adrian_Chadd?= Date: Sun, 7 Jul 2013 09:32:51 +0200 Mime-Version: 1.0 In-Reply-To: <20130707154526.O26496@sola.nimnet.asn.au> References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-acpi=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-stable=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-usb=40freebsd=2Eorg?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 07:32:56 -0000 Hi,=0D=0A=0D=0AFYI: The USB stack will currently run a complete controlle= r reset upon resume, like during boot.=0D=0A=0D=0A--HPS=20=0D=0A=0D=0A=20= =0D=0A-----Original message-----=0D=0A> From:Ian Smith >=0D=0A> Sent: Sunday 7th July 2013 7= :52=0D=0A> To: Adrian Chadd >=0D=0A> Cc: freebsd-acpi@freebsd.org ; freebsd-stable@freebsd.org ; free= bsd-usb@freebsd.org =20=0D=0A> Subject: R= e: USB ports on Lenovo T400 do not work after a suspend/resume=0D=0A>=20=0D= =0A> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:=0D=0A> > On= 30 June 2013 07:22, Ian Smith > wrote:=0D=0A> [..]=0D=0A> > > Nothing of note that I can see= , if that usb hub-to-bus remapping is=0D=0A> > > normal. As you said, '= CPU0: local APIC error 0x40' looks maybe sus.=0D=0A> > > Maybe someone w= ho knows might comment on that=3F=0D=0A>=20=0D=0A> Does noone know what t= hat signifies=3F Maybe it's not relevant to this.=0D=0A>=20=0D=0A> > > = Just checking: you've tried other USB devices apart from uftdi0=3F=0D=0A>= >=20=0D=0A> > Yup, there's no 5v on the port.=0D=0A>=20=0D=0A> I was r= ather taken aback to hear this. Would not this indicate a=20=0D=0A> fail= ure to reinitialise the basic underlying USB hardware on resume=3F=0D=0A>= =20=0D=0A> More than a bit bemused, Ian=0D=0A> __________________________= _____________________=0D=0A> freebsd-acpi@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailman/list= info/freebsd-acpi =20=0D=0A> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@fr= eebsd.org "=0D=0A>=20=0D=0A= =0D=0A From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 10:26:42 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 07763A53; Sun, 7 Jul 2013 10:26:42 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id B15201E3A; Sun, 7 Jul 2013 10:26:41 +0000 (UTC) Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id AA0BC172071; Sun, 7 Jul 2013 12:26:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TiBcnnYtprZp; Sun, 7 Jul 2013 12:26:29 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 09BE7172081; Sun, 7 Jul 2013 12:26:25 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 46AE973A31; Sun, 7 Jul 2013 03:26:24 -0700 (PDT) Date: Sun, 7 Jul 2013 03:26:24 -0700 From: Jeremy Chadwick To: Ian Smith Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-ID: <20130707102624.GB51445@icarus.home.lan> References: <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707154526.O26496@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130707154526.O26496@sola.nimnet.asn.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 10:26:42 -0000 On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote: > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > > On 30 June 2013 07:22, Ian Smith wrote: > [..] > > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > > Maybe someone who knows might comment on that? > > Does noone know what that signifies? Maybe it's not relevant to this. It's too vague to know. The error comes from lapic_handle_error(), which is a generic/small routine which pulls the local APIC error status register. (Note I'm saying APIC, not ACPI -- two different things) apic_vector.S sets this up/makes use of this function, and its done as an interrupt handler. I think this is one of those situations where you have to know *what* is being set up/done at that moment in time for the error code to mean something. Maybe booting verbose would give more information as to what was being done that lead up to the line. I've CC'd John Baldwin who might have some ideas. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 15:57:50 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8C0F563A; Sun, 7 Jul 2013 15:57:50 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id C5FB2197E; Sun, 7 Jul 2013 15:57:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r67FvenY083581; Mon, 8 Jul 2013 01:57:41 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 8 Jul 2013 01:57:40 +1000 (EST) From: Ian Smith To: Jeremy Chadwick Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: <20130707102624.GB51445@icarus.home.lan> Message-ID: <20130708010728.I26496@sola.nimnet.asn.au> References: <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707154526.O26496@sola.nimnet.asn.au> <20130707102624.GB51445@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Adrian Chadd , freebsd-stable@freebsd.org, freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:57:50 -0000 On Sun, 7 Jul 2013 03:26:24 -0700, Jeremy Chadwick wrote: > On Sun, Jul 07, 2013 at 03:51:12PM +1000, Ian Smith wrote: > > On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > > > On 30 June 2013 07:22, Ian Smith wrote: > > [..] > > > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > > > Maybe someone who knows might comment on that? > > > > Does noone know what that signifies? Maybe it's not relevant to this. > > It's too vague to know. The error comes from lapic_handle_error(), > which is a generic/small routine which pulls the local APIC error status > register. (Note I'm saying APIC, not ACPI -- two different things) Indeed; I've been familiar with PICs since c.'79. Googling to check what the 'A' stood for I found this .. from '97 but usefully descriptive perhaps: http://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt I also found this from March 2011 involving Mike Tancsa, you and jhb@ :) http://freebsd.1045724.n5.nabble.com/CPU0-local-APIC-error-0x40-CPU1-local-APIC-error-0x40-td3961805.html > apic_vector.S sets this up/makes use of this function, and its done as > an interrupt handler. Whether an (unserviced?) interrupt error is related to Adrian's symptom - apparent total failure of USB reinitialisation on resume, but only if no USB devices exist in the external slots - remains to be seen. hps@ has just confirmed that it should work the same as on boot, but then this error was flagged on boot - perhaps it also manifests on resume? > I think this is one of those situations where you have to know *what* is > being set up/done at that moment in time for the error code to mean > something. Maybe booting verbose would give more information as to what > was being done that lead up to the line. > > I've CC'd John Baldwin who might have some ideas. Thanks. We have verbose dmesg already. Thread starts (in -stable) at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073917.html and amidst some wild goose chases, pointer to verbose dmesg etc is at http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/074018.html cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 16:43:25 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CDCCDEF7; Sun, 7 Jul 2013 16:43:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2D21B43; Sun, 7 Jul 2013 16:43:25 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id cm16so1894825qab.14 for ; Sun, 07 Jul 2013 09:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oqRSwjqjtjHnzuZyX+U/6kqA7lnvdRcadvBcb6zCPd0=; b=QHr1MjgupfLnw5jBRAuSYXbY7e+fJdBrzNvUhSlGXm7SftWIobORMdUMKBJH6GlNbv 7gmNrgvdrn65djQVePFACyHNaRb4pBuERhcWbd04P6WBQM7cO4lqehqV4G5RJ2isytN/ KSE563en5GVgaWXX2DGdSzM9rlT2nKhoYKmQ7KfGu9avKVE72nf3dgISwoaWXnjuVtnx UY8fD5Lfr6jHoNYbydhNQWSM2nNNlxji4cPfX1wxAV9YqrbISVJM4kPrwDlAURS/1KDs ZbiTwTZ3JixON+EqWErNpGiYa97s7M2tLsf3in2k+ESbuJaKttmA4DkXO6JySS+TmqI3 C1qQ== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr15352480qaz.12.1373215404960; Sun, 07 Jul 2013 09:43:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 09:43:24 -0700 (PDT) In-Reply-To: References: <20130707154526.O26496@sola.nimnet.asn.au> Date: Sun, 7 Jul 2013 09:43:24 -0700 X-Google-Sender-Auth: DxoDALKniHbkuQ_Q2nwEihem8Kg Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-acpi@freebsd.org" , "freebsd-stable@freebsd.org" , Ian Smith , "freebsd-usb@freebsd.org" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:43:25 -0000 I don't think it's a USB controller issue. Those ports are connected to USB hubs, right? I wonder if there's some ACPI nonsense that's resulting in the hubs not being powered up on resume. -adrian On 7 July 2013 00:32, Hans Petter Selasky wrote: > Hi, > > FYI: The USB stack will currently run a complete controller reset upon > resume, like during boot. > > --HPS > > > > -----Original message----- >> From:Ian Smith >> Sent: Sunday 7th July 2013 7:52 >> To: Adrian Chadd >> Cc: freebsd-acpi@freebsd.org; freebsd-stable@freebsd.org; >> freebsd-usb@freebsd.org >> Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume >> >> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: >> > On 30 June 2013 07:22, Ian Smith wrote: >> [..] >> > > Nothing of note that I can see, if that usb hub-to-bus remapping is >> > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. >> > > Maybe someone who knows might comment on that? >> >> Does noone know what that signifies? Maybe it's not relevant to this. >> >> > > Just checking: you've tried other USB devices apart from uftdi0? >> > >> > Yup, there's no 5v on the port. >> >> I was rather taken aback to hear this. Would not this indicate a >> failure to reinitialise the basic underlying USB hardware on resume? >> >> More than a bit bemused, Ian >> _______________________________________________ >> 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" >> From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 18:22:10 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DC812CB; Sun, 7 Jul 2013 18:22:10 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id BD00B1EB9; Sun, 7 Jul 2013 18:22:09 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id C80B27A164; Sun, 7 Jul 2013 20:22:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id B27FD8ED91E; Sun, 7 Jul 2013 20:22:01 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsTsjjU6WgbT; Sun, 7 Jul 2013 20:22:00 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 779DC8ED91D; Sun, 7 Jul 2013 20:22:00 +0200 (CEST) Subject: RE: USB ports on Lenovo T400 do not work after a suspend/resume From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Adrian_Chadd?= Date: Sun, 7 Jul 2013 20:22:00 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-acpi=40freebsd=2Eorg?= , =?utf-8?Q?freebsd-stable=40freebsd=2Eorg?= , =?utf-8?Q?Ian_Smith?= , =?utf-8?Q?freebsd-usb=40?= =?utf-8?Q?freebsd=2Eorg?= X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 18:22:10 -0000 Hi,=0D=0A=0D=0AThe USB code should re-attach the uhub driver to the root = HUB and any other HUBs after resume. Part of the attach code is to set th= e power on.=0D=0A=0D=0ASee /sys/dev/usb/usb_hub.c=0D=0A=0D=0AAnd:=0D=0A=0D= =0Agrep -r UHF_PORT_POWER /sys/dev/usb/=0D=0A=0D=0A--HPS=0D=0A=20=0D=0A=20= =0D=0A-----Original message-----=0D=0A> From:Adrian Chadd >=0D=0A> Sent: Sunday 7th July 2013 18= :43=0D=0A> To: Hans Petter Selasky >=0D=0A> Cc: freebsd-acpi@freebsd.org= ; freebsd-stable@freebsd.org ; Ian Smith >; freebsd-usb@freebsd.org =20=0D=0A> Subject: Re: USB ports on Lenovo T400 do not work after a = suspend/resume=0D=0A>=20=0D=0A> I don't think it's a USB controller issue= =2E=0D=0A>=20=0D=0A> Those ports are connected to USB hubs, right=3F I wo= nder if there's some=0D=0A> ACPI nonsense that's resulting in the hubs no= t being powered up on=0D=0A> resume.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>= -adrian=0D=0A>=20=0D=0A> On 7 July 2013 00:32, Hans Petter Selasky=0D=0A= > > wrote:=0D=0A> > Hi,=0D=0A> >=0D=0A> > FYI: The USB stack will curren= tly run a complete controller reset upon=0D=0A> > resume, like during boo= t.=0D=0A> >=0D=0A> > --HPS=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -----Origi= nal message-----=0D=0A> >> From:Ian Smith >=0D=0A> >> Sent: Sunday 7th July 2013 7:52=0D=0A> >= > To: Adrian Chadd >=0D=0A= > >> Cc: freebsd-acpi@freebsd.org ; fre= ebsd-stable@freebsd.org ;=0D=0A> >> f= reebsd-usb@freebsd.org =20=0D=0A> >> Subj= ect: Re: USB ports on Lenovo T400 do not work after a suspend/resume=0D=0A= > >>=0D=0A> >> On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote:=0D= =0A> >> > On 30 June 2013 07:22, Ian Smith > wrote:=0D=0A> >> [..]=0D=0A> >> > > Nothing of = note that I can see, if that usb hub-to-bus remapping is=0D=0A> >> > > n= ormal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus.=0D=0A= > >> > > Maybe someone who knows might comment on that=3F=0D=0A> >>=0D=0A= > >> Does noone know what that signifies=3F Maybe it's not relevant to t= his.=0D=0A> >>=0D=0A> >> > > Just checking: you've tried other USB devic= es apart from uftdi0=3F=0D=0A> >> >=0D=0A> >> > Yup, there's no 5v on t= he port.=0D=0A> >>=0D=0A> >> I was rather taken aback to hear this. Woul= d not this indicate a=0D=0A> >> failure to reinitialise the basic underly= ing USB hardware on resume=3F=0D=0A> >>=0D=0A> >> More than a bit bemused= , Ian=0D=0A> >> _______________________________________________=0D=0A> >>= freebsd-acpi@freebsd.org mailing list= =0D=0A> >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi =20=0D=0A> >> To unsubsc= ribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org "=0D=0A> >>=0D=0A> ____________________= ___________________________=0D=0A> freebsd-acpi@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailma= n/listinfo/freebsd-acpi =20=0D=0A> To unsubscribe, send any mail to "freebsd-acpi-unsubscr= ibe@freebsd.org "=0D=0A>=20= =0D=0A=0D=0A From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 7 20:50:01 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8149CE88; Sun, 7 Jul 2013 20:50:01 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4004F161F; Sun, 7 Jul 2013 20:50:00 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 197816A6005; Sun, 7 Jul 2013 22:49:59 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id r67Knw0S069458; Sun, 7 Jul 2013 22:49:58 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id r67KnvSB068983; Sun, 7 Jul 2013 22:49:57 +0200 (CEST) (envelope-from lars) Date: Sun, 7 Jul 2013 22:49:57 +0200 From: Lars Engels To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-ID: <20130707204957.GD88288@e-new.0x20.net> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jCtUVa7WgqJFqiey" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.4-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 20:50:01 -0000 --jCtUVa7WgqJFqiey Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: > On 30 June 2013 07:22, Ian Smith wrote: >=20 > > After removing [numbers] (for WITNESS?), diff started making sense. > > The below is between the first and second suspend/resume cycles in > > dmesg-3.txt, encompassing the others. >=20 > Cool! >=20 > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > Maybe someone who knows might comment on that? > > > > Just checking: you've tried other USB devices apart from uftdi0? >=20 > Yup, there's no 5v on the port. Oh, BTW: can you check if you have power on the ports after the first resume and no power after all next resumes until you reboot your notebook? That's the situation I had and maybe it can lead to something. ;) --jCtUVa7WgqJFqiey Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHZ1HUACgkQKc512sD3afjaBQCfRFbhECzF/rGjcNvsb6oCYrTc xCsAoKg6UrgtLtAMOLTVstVF18b9Og8V =xpuU -----END PGP SIGNATURE----- --jCtUVa7WgqJFqiey-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 01:47:04 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3420B494; Mon, 8 Jul 2013 01:47:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by mx1.freebsd.org (Postfix) with ESMTP id C79551FC6; Mon, 8 Jul 2013 01:47:03 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id d13so5480129qak.9 for ; Sun, 07 Jul 2013 18:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Q9kXV1UZOmOglVLUGGHePTC0SKFwfzoN7M43v67FSvw=; b=pTivoVDlc/mWWU6plQuaTNGrcn/1h8cJyniaRiveKPr9UYoYkL1xGs8HMC5861Y9Ej TZXxVCi0kOWVYaPye3vSxJo2nm7kTYsI9Dzn/px+x9hQQSQ/kf+ZU5buDdkqNVrnRKq3 Bg9K7ZUtbHhnXijPkR9LDgiNtiaQwgVmlxIfv4ycC1CRgb9hNQ535UpbCRkGJUe7qNK3 IVTMZMYn9mrIoXDKdJyUHskrO/Si/HHShx46YRevfgrxcGcZRfyJUTD24jQthuW9AsNX Dkjb+GIRhd4hnZfioHCLMM4q3vDDLG/3iXKDJwKVdO5W711+STRRCIc/RcuwstvE9y0G g9bg== MIME-Version: 1.0 X-Received: by 10.49.117.195 with SMTP id kg3mr13929647qeb.68.1373248023418; Sun, 07 Jul 2013 18:47:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 18:47:03 -0700 (PDT) In-Reply-To: <20130707204957.GD88288@e-new.0x20.net> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> Date: Sun, 7 Jul 2013 18:47:03 -0700 X-Google-Sender-Auth: 0i847bi-sS21nTIFcyBUCzOEboo Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Lars Engels Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 01:47:04 -0000 Nope, no power after first resume if i have nothing plugged in. Why? -adrian On 7 July 2013 13:49, Lars Engels wrote: > On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: >> On 30 June 2013 07:22, Ian Smith wrote: >> >> > After removing [numbers] (for WITNESS?), diff started making sense. >> > The below is between the first and second suspend/resume cycles in >> > dmesg-3.txt, encompassing the others. >> >> Cool! >> >> > Nothing of note that I can see, if that usb hub-to-bus remapping is >> > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. >> > Maybe someone who knows might comment on that? >> > >> > Just checking: you've tried other USB devices apart from uftdi0? >> >> Yup, there's no 5v on the port. > > Oh, BTW: can you check if you have power on the ports after the first > resume and no power after all next resumes until you reboot your > notebook? > That's the situation I had and maybe it can lead to something. ;) From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 05:00:44 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7404ADEE; Mon, 8 Jul 2013 05:00:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A8C3317D3; Mon, 8 Jul 2013 05:00:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6850XOb012097; Mon, 8 Jul 2013 15:00:34 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 8 Jul 2013 15:00:33 +1000 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume In-Reply-To: Message-ID: <20130708140804.R26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 05:00:44 -0000 On Sun, 7 Jul 2013 18:47:03 -0700, Adrian Chadd wrote: > On 7 July 2013 13:49, Lars Engels wrote: > > On Sun, Jun 30, 2013 at 03:02:57PM -0700, Adrian Chadd wrote: > >> On 30 June 2013 07:22, Ian Smith wrote: > >> > >> > After removing [numbers] (for WITNESS?), diff started making sense. > >> > The below is between the first and second suspend/resume cycles in > >> > dmesg-3.txt, encompassing the others. > >> > >> Cool! > >> > >> > Nothing of note that I can see, if that usb hub-to-bus remapping is > >> > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > >> > Maybe someone who knows might comment on that? > >> > > >> > Just checking: you've tried other USB devices apart from uftdi0? > >> > >> Yup, there's no 5v on the port. > > > > Oh, BTW: can you check if you have power on the ports after the first > > resume and no power after all next resumes until you reboot your > > notebook? > > That's the situation I had and maybe it can lead to something. ;) > Nope, no power after first resume if i have nothing plugged in. > > Why? Checking one more point .. do the USB ports come up ok if you originally boot with nothing plugged in? If so (or if not), does that local APIC error message appear the same then too? cheers, Ian PS OT: finally found a USB keyboard but I'd forgotten that my friend's machine is an SL500, not T500. Moreover, because its keyboard+trackpad etc is non-working (internally disconnected), I have no way to resume it without the kbd (and the 9.1-R memstick) plugged in. Even with kbd and memstick left in and using acpiconf -s3 it suspends ok but is hung after resume by dabbing power button; no screen and kbd is dead too - sorry, no help there. OTOH my son just bought a refurb T430 ('doze 7, beats 8 anyway) which I should get to play with a bit this week. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 11:41:07 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C032A53C for ; Mon, 8 Jul 2013 11:41:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 993F5147E for ; Mon, 8 Jul 2013 11:41:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r68BeXfW053981 for ; Mon, 8 Jul 2013 11:41:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68B6W0j046059 for freebsd-acpi@FreeBSD.org; Mon, 8 Jul 2013 11:06:32 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jul 2013 11:06:32 GMT Message-Id: <201307081106.r68B6W0j046059@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 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:41:07 -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/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v 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/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 i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not 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/73823 acpi [request] acpi / power-on by timer support 25 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 18:09:22 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07FED92E; Mon, 8 Jul 2013 18:09:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 99A071F9F; Mon, 8 Jul 2013 18:09:21 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id o13so5837972qaj.3 for ; Mon, 08 Jul 2013 11:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yJydbRwd6PxXwUMlvhN411HLag+l4AamyHGFS8x77c8=; b=FBJsw8DVFVFNWO3SIKSPj9+kO7yrOXZcBM7GlrgM8ag0F18ScN8wIKEWygsFhm3pWH zX6OWoBAkXsNOxZ2r7qrIJUOBmt5APWGlPSbRMkUjv5EyB1b6vqtjQ5kH5fJhiWnw8xG KiJtT05lUQqgOU9lJTsZhF2trDPOt8u9XCtvLM7vcih4rebQexIqMshET2AB69RJzQGl Y1wuF7HyKZgPjaE+N1K1n64Gy1F2bUkCV9yJPBEDxTO5FGTcMHDeTygxHlvBTtu+nELe 5ZSiXFP+iE2blVSPVGtLvdm74RQRSHvAH0ZJhX/0UoTpvJLZJr+qjTTyqP72G2iRmbf0 3O/g== MIME-Version: 1.0 X-Received: by 10.49.98.196 with SMTP id ek4mr17422401qeb.8.1373306960685; Mon, 08 Jul 2013 11:09:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Mon, 8 Jul 2013 11:09:20 -0700 (PDT) In-Reply-To: <20130708140804.R26496@sola.nimnet.asn.au> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> Date: Mon, 8 Jul 2013 11:09:20 -0700 X-Google-Sender-Auth: S_B-uP8VnjrSV5MDjKn5BderDAI Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 18:09:22 -0000 On 7 July 2013 22:00, Ian Smith wrote: > Checking one more point .. do the USB ports come up ok if you originally > boot with nothing plugged in? If so (or if not), does that local APIC Yes. > error message appear the same then too? > No -adrian From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 21:26:08 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FDBD70B; Mon, 8 Jul 2013 21:26:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2361A0F; Mon, 8 Jul 2013 21:26:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1E2F3B93B; Mon, 8 Jul 2013 17:26:07 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Date: Mon, 8 Jul 2013 14:19:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130630233640.Y23789@sola.nimnet.asn.au> In-Reply-To: <20130630233640.Y23789@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201307081419.42478.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 08 Jul 2013 17:26:07 -0400 (EDT) Cc: Adrian Chadd , freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:26:08 -0000 On Sunday, June 30, 2013 10:22:09 am Ian Smith wrote: > On Sat, 29 Jun 2013, Adrian Chadd wrote: > > On 27 June 2013 04:58, Ian Smith wrote: > > > We don't yet know if this is a bus, ACPI &/or USB issue. Home yet? = :) > >=20 > > Yup: > >=20 > > http://people.freebsd.org/~adrian/usb/ > >=20 > > dmesg.boot =3D dmesg at startup > >=20 > > 1 - after powerup, usb device in > > 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in > > 3 - after acpiconf -s3 suspend/resume, with a USB device removed > > before suspend/resume >=20 > After removing [numbers] (for WITNESS?), diff started making sense. =20 > The below is between the first and second suspend/resume cycles in=20 > dmesg-3.txt, encompassing the others. >=20 > Nothing of note that I can see, if that usb hub-to-bus remapping is=20 > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. =20 > Maybe someone who knows might comment on that? =46rom sys/amd64/include/apicreg.h: /* fields in ESR */ #define APIC_ESR_SEND_CS_ERROR 0x00000001 #define APIC_ESR_RECEIVE_CS_ERROR 0x00000002 #define APIC_ESR_SEND_ACCEPT 0x00000004 #define APIC_ESR_RECEIVE_ACCEPT 0x00000008 #define APIC_ESR_SEND_ILLEGAL_VECTOR 0x00000020 #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x00000040 #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 Receive illegal vector (if look in Intel's SDM manuals) means it got an interrupt vector < 32 (probably zero). Perhaps it asserted an interrupt in an I/O APIC before the I/O APIC was properly reset? Are you using MSI at all? =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 8 23:09:25 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8784416F; Mon, 8 Jul 2013 23:09:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 180581E28; Mon, 8 Jul 2013 23:09:25 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id 1so2673118qec.34 for ; Mon, 08 Jul 2013 16:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BqHtD6EqVhfBpO+713df/dtZ4aqhj/S+USiMeHrxnrI=; b=cMwQGgHOSFtLDV3B1dqvaMeYZxP/gp1zEcqA7rIDrhJoUFAGtSvq8FmLVRiSn/P7mo GXEbvi9He1PSMrmMyujClO0AkRFmtN0L4NGw2n9tdTeAeJxJDglN81VXC46d9vML6z+y Y2maTZLpezR3u2i7uwsIsSOmrmPXjB6uYdnrdfqs62fl6kFuLxWz9V1Bbq0dKOEpzlyo tOO4ptg9eHtQ84+iIOFm9DkUvkHnqHf8/Pb78VRmlQnsmf0e0b9FAFdwJpAU+8h6xxpu KiQLDws7hQonSvpQERReJ50dGkjBt1V4w7eaGpk536x3udtPpZrQhoIoZHAyDDNQMnbu lOGg== MIME-Version: 1.0 X-Received: by 10.49.58.70 with SMTP id o6mr17799524qeq.1.1373324964711; Mon, 08 Jul 2013 16:09:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Mon, 8 Jul 2013 16:09:24 -0700 (PDT) In-Reply-To: <201307081419.42478.jhb@freebsd.org> References: <20130630233640.Y23789@sola.nimnet.asn.au> <201307081419.42478.jhb@freebsd.org> Date: Mon, 8 Jul 2013 16:09:24 -0700 X-Google-Sender-Auth: QP0zCszBEe4Geh31Xtl5La1WT_I Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 23:09:25 -0000 On 8 July 2013 11:19, John Baldwin wrote: > From sys/amd64/include/apicreg.h: This system runs an i386 kernel. > /* fields in ESR */ > #define APIC_ESR_SEND_CS_ERROR 0x00000001 > #define APIC_ESR_RECEIVE_CS_ERROR 0x00000002 > #define APIC_ESR_SEND_ACCEPT 0x00000004 > #define APIC_ESR_RECEIVE_ACCEPT 0x00000008 > #define APIC_ESR_SEND_ILLEGAL_VECTOR 0x00000020 > #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x00000040 > #define APIC_ESR_ILLEGAL_REGISTER 0x00000080 > > Receive illegal vector (if look in Intel's SDM manuals) means it > got an interrupt vector < 32 (probably zero). Perhaps it asserted > an interrupt in an I/O APIC before the I/O APIC was properly reset? > Are you using MSI at all? I think iwn uses MSI. I'm sure other hardware in here does. I can dig through it and let you know. -adrian From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 9 06:23:48 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B81AC8EB; Tue, 9 Jul 2013 06:23:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id EB1631AA0; Tue, 9 Jul 2013 06:23:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6965bio065085; Tue, 9 Jul 2013 16:05:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 9 Jul 2013 16:05:37 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130709145722.U61164@sola.nimnet.asn.au> References: <20130707003651.Y26496@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 06:23:48 -0000 On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote: > On Sun, 7 Jul 2013, Ian Smith wrote: > > > So even if cpu_running_mark were 100% (-r100), anything busier than 25% > > of our example 75MHz would shift to maximum freq immediately, where the > > load will likely plummet to just a few percent, way less than the 25% > > (at -r100) needed to keep it at that freq; ie it will most likely hunt. > > It may do that, but if so it's doing it more quickly than is visible running > powerd -a hyper -n hyper -v. Apart from some possible under-the-hood adjustment by thermal control in an over-temperature situation (?) and /etc/rc.d/power_profile poking the freq on AC/battery changes (not applicable to yours), as far as I know the only thing that adjusts freqs is powerd itself. So no, it's not hunting for you. But then, due to you having disabled p4tcc and acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry from the up to 32:1 sort of ranges seen with p4tcc etc enabled. What I'm concerned about is what happens engaging your hyper mode with out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by default. Would you care to find out? :) I have no means to do so. > > You don't appear to be taking any notice of the -i idle percentage here; > > perhaps that would be a more useful shift-down criterion? Even so, with > > a full house of frequencies, I can't see this being easy to tune as is. > > > > Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on? > > And your powerd_flags setting? > > /boot/loader.conf: > hint.p4tcc.0.disabled="1" > hint.acpi_throttle.0.disabled="1" > hw.acpi.cpu.cx_lowest="C3" > > I've routinely used the first two since first reading about them, I think in > another post by Kevin. Indeed, Kevin's been chewing on this bone for quite some time :) but I don't know if there's any PR + simple patch that may attract attention? I also don't know if the situation is the same on AMD CPUs, or others. > /etc/rc.conf: > powerd_flags="-a hyper -n hyper" Still on 9.1 at least, #define DEFAULT_ACTIVE_PERCENT 75 #define DEFAULT_IDLE_PERCENT 50 #define DEFAULT_POLL_INTERVAL 250 /* Poll interval in milliseconds */ So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% after 250mS. I use 200mS and there's no impact on powerd CPU usage even at my idle 733MHz; your responsiveness may benefit from using say 100mS? > performance_cx_lowest="Cmax" > performance_cpu_freq="HIGH" > > That grep provides a lot of unrelated "freq" stuff, so here's a guess at what > you want to see: Yes, I tried it on a borrowed Lenovo SL500; lots more than on my T23! > hw.acpi.cpu.cx_lowest: C8 Never heard of C8, but I'm way out of touch with latest hardware. > machdep.acpi_timer_freq: 3579545 > machdep.i8254_freq: 1193182 > machdep.tsc_freq: 3309792585 > dev.cpu.0.freq: 3601 > dev.cpu.0.freq_levels: 3601/300000 3600/300000 3500/300000 3400/300000 > 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 > 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 > 2100/182000 2000/163000 1600/91000 Interesting specifying 300W right down to 2500MHz before decreasing, and it's quite a large set of primary freqs, only 4 on one 2400MHz Core2Duo. > dev.cpu.0.cx_supported: C1/1/1 C2/2/64 C3/3/96 > dev.cpu.0.cx_lowest: C8 > dev.cpu.0.cx_usage: 31.99% 64.88% 3.12% last 1203us Some changes in -current there. cpu.1.* to cpu.3.* the same as usual, apart from varying cx_usage, so you can safely omit them from reports. [..] > dev.est.0.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 > 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 > 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 > 2100/182000 2000/163000 1600/91000 [.. same as freq_levels, without throttling ..] > This is an i5, with the "3601" being turbo mode. With that beast I'm amazed you can really notice slower responsiveness w/ 4 CPUs @ 1600MHz, but then I get by with a P3-M at 1133/733MHz :) It would be interesting to see cpu.0.freq_levels, est.0.freq_settings and the p4tcc.0 settings - and whether it hunts - with default tuning on some sort of lightish load - perhaps a big find like on the daily runs? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 9 18:40:13 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9B25E93; Tue, 9 Jul 2013 18:40:13 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9572C12F6; Tue, 9 Jul 2013 18:40:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r69IeCle047392; Tue, 9 Jul 2013 12:40:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r69IeBvm047389; Tue, 9 Jul 2013 12:40:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 9 Jul 2013 12:40:11 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130709145722.U61164@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 09 Jul 2013 12:40:12 -0600 (MDT) Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:40:14 -0000 On Tue, 9 Jul 2013, Ian Smith wrote: > On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote: > > On Sun, 7 Jul 2013, Ian Smith wrote: > > > > > So even if cpu_running_mark were 100% (-r100), anything busier than 25% > > > of our example 75MHz would shift to maximum freq immediately, where the > > > load will likely plummet to just a few percent, way less than the 25% > > > (at -r100) needed to keep it at that freq; ie it will most likely hunt. > > > > It may do that, but if so it's doing it more quickly than is visible running > > powerd -a hyper -n hyper -v. > > Apart from some possible under-the-hood adjustment by thermal control in > an over-temperature situation (?) and /etc/rc.d/power_profile poking the > freq on AC/battery changes (not applicable to yours), as far as I know > the only thing that adjusts freqs is powerd itself. So no, it's not > hunting for you. But then, due to you having disabled p4tcc and > acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry > from the up to 32:1 sort of ranges seen with p4tcc etc enabled. > > What I'm concerned about is what happens engaging your hyper mode with > out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by > default. Would you care to find out? :) I have no means to do so. > > /boot/loader.conf: > > hint.p4tcc.0.disabled="1" > > hint.acpi_throttle.0.disabled="1" > > hw.acpi.cpu.cx_lowest="C3" Commenting those entries out gives: dev.cpu.0.freq_levels: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1750/142625 1600/91000 1400/79625 1200/68250 1000/56875 800/45500 600/34125 400/22750 200/11375 dev.est.0.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 With only that change and powerd running in hyper mode, it subjectively feels slower to start things. > > I've routinely used the first two since first reading about them, I think in > > another post by Kevin. > > Indeed, Kevin's been chewing on this bone for quite some time :) but I > don't know if there's any PR + simple patch that may attract attention? > I also don't know if the situation is the same on AMD CPUs, or others. > > > /etc/rc.conf: > > powerd_flags="-a hyper -n hyper" > > Still on 9.1 at least, > #define DEFAULT_ACTIVE_PERCENT 75 > #define DEFAULT_IDLE_PERCENT 50 > #define DEFAULT_POLL_INTERVAL 250 /* Poll interval in milliseconds */ > > So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% > after 250mS. I use 200mS and there's no impact on powerd CPU usage even > at my idle 733MHz; your responsiveness may benefit from using say 100mS? Interesting point. 100mS is a perceptible lag. It occurs to me that CPU load is really a poor predictor of what is happening on an interactive session. powerd ought to have a wakeup signal. On a keypress or mouse move or some other type of user input, powerd would jump to the highest frequency of the current profile. It does not matter as much how it decides to drop back down. Using devd to switch powerd profiles would be interesting. powerd would have to be able to switch profiles while running, I think. Maybe startup cost is not that high. > > This is an i5, with the "3601" being turbo mode. > > With that beast I'm amazed you can really notice slower responsiveness > w/ 4 CPUs @ 1600MHz, but then I get by with a P3-M at 1133/733MHz :) Some would say I'm more particular about it than most people. I just say I want it faster. :) > It would be interesting to see cpu.0.freq_levels, est.0.freq_settings > and the p4tcc.0 settings - and whether it hunts - with default tuning on > some sort of lightish load - perhaps a big find like on the daily runs? Timing 'periodic daily' now with a full cache and powerd not running: 995.53 real 28.15 user 132.17 sys With 'powerd -a hyper -n hyper -v > /tmp/powerd.log': 2322.06 real 58.72 user 305.22 sys Load varied enough that it would drop to 200MHz quite often. Picking a random part of the log: load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 11%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 0%, current freq 200 MHz (26), wanted freq 200 MHz load 10%, current freq 200 MHz (26), wanted freq 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 55%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 4%, current freq 3601 MHz ( 0), wanted freq 200 MHz changing clock speed from 3601 MHz to 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 20%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz changing clock speed from 3601 MHz to 200 MHz load 4%, current freq 200 MHz (26), wanted freq 200 MHz now operating on AC power; changing frequency to 3601 MHz load 21%, current freq 200 MHz (26), wanted freq 3601 MHz changing clock speed from 200 MHz to 3601 MHz now operating on AC power; changing frequency to 200 MHz load 0%, current freq 3601 MHz ( 0), wanted freq 200 MHz From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 10 10:06:05 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0267C1B; Wed, 10 Jul 2013 10:06:05 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 25B8810B8; Wed, 10 Jul 2013 10:06:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6AA5ubh023725; Wed, 10 Jul 2013 20:05:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 10 Jul 2013 20:05:56 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130710200113.J23480@sola.nimnet.asn.au> References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 10:06:06 -0000 On Tue, 9 Jul 2013 12:40:11 -0600, Warren Block wrote: > On Tue, 9 Jul 2013, Ian Smith wrote: > > On Sat, 6 Jul 2013 20:09:46 -0600, Warren Block wrote: > > > On Sun, 7 Jul 2013, Ian Smith wrote: [..] > > the only thing that adjusts freqs is powerd itself. So no, it's not > > hunting for you. But then, due to you having disabled p4tcc and > > acpi_throttle, your lowest speed is 1600, only 1/2.25 x 3600, a far cry > > from the up to 32:1 sort of ranges seen with p4tcc etc enabled. > > > > What I'm concerned about is what happens engaging your hyper mode with > > out-of-the-box settings, ie with p4tcc or acpi_throttle enabled as by > > default. Would you care to find out? :) I have no means to do so. > > > > /boot/loader.conf: > > > hint.p4tcc.0.disabled="1" > > > hint.acpi_throttle.0.disabled="1" > > > hw.acpi.cpu.cx_lowest="C3" > > Commenting those entries out gives: > > dev.cpu.0.freq_levels: 3601/300000 3600/300000 3500/300000 3400/300000 > 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 > 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 > 2100/182000 2000/163000 1750/142625 1600/91000 1400/79625 1200/68250 > 1000/56875 800/45500 600/34125 400/22750 200/11375 > dev.est.0.freq_settings: 3601/300000 3600/300000 3500/300000 3400/300000 > 3300/300000 3200/300000 3100/300000 3000/300000 2900/300000 2800/300000 > 2700/300000 2600/300000 2500/300000 2400/247000 2300/224000 2200/202000 > 2100/182000 2000/163000 1600/91000 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > 2500/-1 1250/-1 Right, cpufreq has added 1750, 1400, 1200, 1000, 800, 600, 400 and 200, the latter being 1/8 of the lowest absolute freq of 1600, due to p4tcc. That's a range of 18:1, not as bad as 32:1 but still quite a lot. You may find it instructive (though once is probably enough :) to set debug.cpufreq.verbose=1 in loader and watch cpufreq working out which freqs to use from those available. It does prefer absolute freqs, but still uses the relative freqs to setup the lower freqs. There's also debug.cpufreq.lowest, but messing with that requires custom tuning. > With only that change and powerd running in hyper mode, it subjectively feels > slower to start things. At 1/8 the speed, that's not too surprising .. [..] > > > /etc/rc.conf: > > > powerd_flags="-a hyper -n hyper" > > > > Still on 9.1 at least, > > #define DEFAULT_ACTIVE_PERCENT 75 > > #define DEFAULT_IDLE_PERCENT 50 > > #define DEFAULT_POLL_INTERVAL 250 /* Poll interval in milliseconds */ > > > > So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% > > after 250mS. I use 200mS and there's no impact on powerd CPU usage even > > at my idle 733MHz; your responsiveness may benefit from using say 100mS? > > Interesting point. 100mS is a perceptible lag. Maybe just. On that beast I think you could use 50ms with no noticeable powerd CPU usage, maybe even 25ms. In fact I think doing just that with hadp mode might get you all the interactive responsiveness you want, and still let powerd use a range of freqs as required. Playing with -r and -i will also alter the responsiveness curve quite a bit. With it then testing load and increasing frequency 5 times as often, on full load it should shift up 5 times more quickly, and hadp mode already shifts freq up by a factor of 4 on each poll_interval, so it should get from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling, from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 = 3200) with even three steps then taking only 150ms, well inside your current 250ms interval. Maybe give that a try? > It occurs to me that CPU load is really a poor predictor of what is happening > on an interactive session. powerd ought to have a wakeup signal. On a > keypress or mouse move or some other type of user input, powerd would jump to > the highest frequency of the current profile. It does not matter as much how > it decides to drop back down. You're talking about some pretty major kernel hacking, apart from powerd in userland. Maybe getting devd to notify on every keypress and mouse click (mouse movement would be insanely busy) but I think that'd be OTT and get you in far deeper water than you want, I suspect :) > Using devd to switch powerd profiles would be interesting. powerd would have > to be able to switch profiles while running, I think. Maybe startup cost is > not that high. At the moment powerd uses devd notification for AC/battery state changes only. It's using select() with the poll_ival timeout, so it gets those devd events as they occur, otherwise it times out after the poll_ival then tests load vs freq, adjusts if necessary, then back to select(). > > > This is an i5, with the "3601" being turbo mode. > > > > With that beast I'm amazed you can really notice slower responsiveness > > w/ 4 CPUs @ 1600MHz, but then I get by with a P3-M at 1133/733MHz :) > > Some would say I'm more particular about it than most people. I just say I > want it faster. :) Testing load every 50ms should be fast enough. If not, powerd will accept down to 5ms for poll_interval, but that seems excessively busy. The only disadvantage might be extreme verbosity in -v mode :) > > It would be interesting to see cpu.0.freq_levels, est.0.freq_settings > > and the p4tcc.0 settings - and whether it hunts - with default tuning on > > some sort of lightish load - perhaps a big find like on the daily runs? > > Timing 'periodic daily' now with a full cache and powerd not running: > 995.53 real 28.15 user 132.17 sys > > With 'powerd -a hyper -n hyper -v > /tmp/powerd.log': > 2322.06 real 58.72 user 305.22 sys > > Load varied enough that it would drop to 200MHz quite often. Picking a > random part of the log: > > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > load 11%, current freq 200 MHz (26), wanted freq 200 MHz > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > load 10%, current freq 200 MHz (26), wanted freq 200 MHz > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > now operating on AC power; changing frequency to 3601 MHz > load 55%, current freq 200 MHz (26), wanted freq 3601 MHz > changing clock speed from 200 MHz to 3601 MHz > now operating on AC power; changing frequency to 200 MHz > load 4%, current freq 3601 MHz ( 0), wanted freq 200 MHz > changing clock speed from 3601 MHz to 200 MHz > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > now operating on AC power; changing frequency to 3601 MHz > load 20%, current freq 200 MHz (26), wanted freq 3601 MHz > changing clock speed from 200 MHz to 3601 MHz > now operating on AC power; changing frequency to 200 MHz > load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz > changing clock speed from 3601 MHz to 200 MHz > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > now operating on AC power; changing frequency to 3601 MHz > load 21%, current freq 200 MHz (26), wanted freq 3601 MHz > changing clock speed from 200 MHz to 3601 MHz > now operating on AC power; changing frequency to 200 MHz > load 0%, current freq 3601 MHz ( 0), wanted freq 200 MHz Hunting away. Over twice as long to run. Maybe now try at 50ms in hadp mode and you'll have a good idea how fast that runs, and how it feels. cheers, Ian (wishing momentarily I had one like yours to play with :) From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 10 19:43:58 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2C7E137; Wed, 10 Jul 2013 19:43:58 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 922D317C4; Wed, 10 Jul 2013 19:43:58 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r6AJhvu5065423; Wed, 10 Jul 2013 13:43:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r6AJhuox065420; Wed, 10 Jul 2013 13:43:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 10 Jul 2013 13:43:56 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130710200113.J23480@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> <20130710200113.J23480@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 10 Jul 2013 13:43:57 -0600 (MDT) Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:43:59 -0000 On Wed, 10 Jul 2013, Ian Smith wrote: > > > > /etc/rc.conf: > > > > powerd_flags="-a hyper -n hyper" > > > > > > Still on 9.1 at least, > > > #define DEFAULT_ACTIVE_PERCENT 75 > > > #define DEFAULT_IDLE_PERCENT 50 > > > #define DEFAULT_POLL_INTERVAL 250 /* Poll interval in milliseconds */ > > > > > > So hyper mode will select max freq if load at 1600MHz is > 75/4 = 18.75% > > > after 250mS. I use 200mS and there's no impact on powerd CPU usage even > > > at my idle 733MHz; your responsiveness may benefit from using say 100mS? > > > > Interesting point. 100mS is a perceptible lag. > > Maybe just. On that beast I think you could use 50ms with no noticeable > powerd CPU usage, maybe even 25ms. In fact I think doing just that with > hadp mode might get you all the interactive responsiveness you want, and > still let powerd use a range of freqs as required. Playing with -r and > -i will also alter the responsiveness curve quite a bit. > > With it then testing load and increasing frequency 5 times as often, on > full load it should shift up 5 times more quickly, and hadp mode already > shifts freq up by a factor of 4 on each poll_interval, so it should get > from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling, > from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 = > 3200) with even three steps then taking only 150ms, well inside your > current 250ms interval. Maybe give that a try? Wow! -r 50 with either hadp or hyper mode feels fine interactively. > > Timing 'periodic daily' now with a full cache and powerd not running: > > 995.53 real 28.15 user 132.17 sys > > > > With 'powerd -a hyper -n hyper -v > /tmp/powerd.log': > > 2322.06 real 58.72 user 305.22 sys > > > > Load varied enough that it would drop to 200MHz quite often. Picking a > > random part of the log: > > > > load 0%, current freq 200 MHz (26), wanted freq 200 MHz > > load 10%, current freq 200 MHz (26), wanted freq 200 MHz > > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > > now operating on AC power; changing frequency to 3601 MHz > > load 55%, current freq 200 MHz (26), wanted freq 3601 MHz > > changing clock speed from 200 MHz to 3601 MHz > > now operating on AC power; changing frequency to 200 MHz > > load 4%, current freq 3601 MHz ( 0), wanted freq 200 MHz > > changing clock speed from 3601 MHz to 200 MHz > > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > > now operating on AC power; changing frequency to 3601 MHz > > load 20%, current freq 200 MHz (26), wanted freq 3601 MHz > > changing clock speed from 200 MHz to 3601 MHz > > now operating on AC power; changing frequency to 200 MHz > > load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz > Hunting away. Is that a bad thing, though? Effectively, it's just PWM, if you see what I mean. > Over twice as long to run. Maybe now try at 50ms in hadp mode and > you'll have a good idea how fast that runs, and how it feels. The same periodic daily test as before, again with the first run discarded to load the cache. powerd -a hyper -n hyper -p 50 -v > /tmp/powerd.log 977.44 real 47.79 user 238.48 sys powerd -a hadp -n hadp -p 50 -v > /tmp/powerd.log 874.18 real 28.89 user 140.00 sys > cheers, Ian (wishing momentarily I had one like yours to play with :) It's nice. :) From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 10 23:51:10 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9704CCAF for ; Wed, 10 Jul 2013 23:51:10 +0000 (UTC) (envelope-from rathaval@uci.edu) Received: from mda1.es.uci.edu (mda1.es.uci.edu [128.200.80.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7793611C9 for ; Wed, 10 Jul 2013 23:51:09 +0000 (UTC) Received: from esmtp3.es.uci.edu (esmtp3.es.uci.edu [128.195.153.133]) by mda1.es.uci.edu (8.13.8/8.13.8) with ESMTP id r6ANnCi3707430 for ; Wed, 10 Jul 2013 16:49:12 -0700 Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (authenticated bits=0) by esmtp3.es.uci.edu (8.13.8/8.13.8) with ESMTP id r6ANn3EO190492 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 10 Jul 2013 16:49:05 -0700 X-UCInetID: rathaval Received: by mail-we0-f181.google.com with SMTP id p58so6165890wes.26 for ; Wed, 10 Jul 2013 16:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=3DO6V1CjiYDcSu6u4fYWk0p+/sCQcliGjLqg2fp5kFw=; b=gEf6zh0l1pYujMMAtjqvk222BvvsQyIrux1qAlYeNRixTYaINEOEl6grk1RKPStLGc SFAUj1Ezn9WK0zOM6xthUWcc1d6aT+B94kk1X0jCwQ5WoIcG8+59WmV5asXvUqiSjcCP vBua6KsSlCgTDUo3Lq6nGrkTNRgi8sZLiFzRz/VCGJCHU+E4yqoAsViaKS0CZYGIclON jP8zo5sYMXcXMANZVmdNsFtcrczXvRJ9SCsJlqniaEfNnmWNSDnfRDPn/J3MTXo9vnnr ixETDD1H3/PnleJMRQNeLd9P7xTPwsTpycOblWJ71TWfCumtiofT/Tr4hy1/oS94NLUp lzmQ== X-Received: by 10.180.198.10 with SMTP id iy10mr36517559wic.29.1373500143030; Wed, 10 Jul 2013 16:49:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.165 with HTTP; Wed, 10 Jul 2013 16:48:42 -0700 (PDT) From: Rohit Athavale Date: Wed, 10 Jul 2013 16:48:42 -0700 Message-ID: Subject: ACPI MADT BSP Details To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 23:51:10 -0000 Hi Folks, I have two questions about discovering the processors from the MADT table. Firstly, Can we find out which processor is the BSP from the MADT tables? When comparing the userland mptable binary's output versus acpidump's output I noticed that mptable informs us about which processor is the BSP and which are AP's . However I did not see this in the MADT tables. Is there a way to find out which processor is the BSP by means of any of the ACPI tables. Secondly, Can we write into /dev/mem to say update the contents of MPTable with values that are non -default. I plan to read some values from the ACPI tables and update the MP tables. Is the /dev/mem/ file composed of physical addresses for user space memory ? I know this may not qualify as the correct place to ask,but I guess acpi list might have an answer to this. Thanks Best Regards, Rohit From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 12 20:51:42 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DA50528 for ; Fri, 12 Jul 2013 20:51:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3605C1E40 for ; Fri, 12 Jul 2013 20:51:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A8E73B96E; Fri, 12 Jul 2013 16:51:40 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: ACPI MADT BSP Details Date: Fri, 12 Jul 2013 16:50:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307121650.41701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Jul 2013 16:51:40 -0400 (EDT) Cc: Rohit Athavale X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:51:42 -0000 On Wednesday, July 10, 2013 7:48:42 pm Rohit Athavale wrote: > Hi Folks, > > I have two questions about discovering the processors from the MADT table. > > Firstly, > Can we find out which processor is the BSP from the MADT tables? > When comparing the userland mptable binary's output versus acpidump's > output I noticed that mptable informs us about which processor is the BSP > and which are AP's . > However I did not see this in the MADT tables. > Is there a way to find out which processor is the BSP by means of any of > the ACPI tables. Nope. You can read the local APIC ID of the current CPU during your bootstrap though. > Secondly, > Can we write into /dev/mem to say update the contents of MPTable with > values that are non -default. I plan to read some values from the ACPI > tables and update the MP tables. > Is the /dev/mem/ file composed of physical addresses for user space memory > ? I know this may not qualify as the correct place to ask,but I guess acpi > list might have an answer to this. Yes, you can likely do this. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 12 21:12:02 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01F74B0F; Fri, 12 Jul 2013 21:12:02 +0000 (UTC) (envelope-from rathaval@uci.edu) Received: from mda2.es.uci.edu (mda2.es.uci.edu [128.200.80.5]) by mx1.freebsd.org (Postfix) with ESMTP id D3EE91F2E; Fri, 12 Jul 2013 21:12:01 +0000 (UTC) Received: from esmtp1.es.uci.edu (esmtp1.es.uci.edu [128.195.153.131]) by mda2.es.uci.edu (8.13.8/8.13.8) with ESMTP id r6CLB6Tu224366; Fri, 12 Jul 2013 14:11:06 -0700 Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (authenticated bits=0) by esmtp1.es.uci.edu (8.13.8/8.13.8) with ESMTP id r6CLAvHx926285 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 12 Jul 2013 14:10:59 -0700 X-UCInetID: rathaval Received: by mail-wg0-f49.google.com with SMTP id a12so8404024wgh.4 for ; Fri, 12 Jul 2013 14:10:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GNjlvdAF1lC1jBODs5BOt83TP++iMYREegT8mq7HDUw=; b=fZCtUB0eGMbwwnXJIrQOyDpso/vX9XHIDGOgssv2651kibQcKWpgHdBYWZGlQ1JSCS 7PHWNiGM7LgwM9f59CkEJtKBGVOy0/2g5yLf3FjW8/lWcz/avQhXPGaBIPAHtQ6guye8 9/bQ6oLa+w3a1EwOFHwyp8e0vKxpXo4+I2x4FBoTRsxvuVXmDX80zvacLs2VlRMMG8sP EhvaAKrV/cqQjaEYykUfnsE2kwHdYSOMiJa7ptReMG9S1A8RZqIYxaF49jMcOcNV+CPh tLkse1CEA0jPPX+C87CdlvO1ZU1Tkx9qx8QSSSZgBtdvCOALbvn9G2xNmFfZwgJVQoYv dOuA== X-Received: by 10.180.211.233 with SMTP id nf9mr2690761wic.41.1373663456692; Fri, 12 Jul 2013 14:10:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.9.165 with HTTP; Fri, 12 Jul 2013 14:10:36 -0700 (PDT) In-Reply-To: <201307121650.41701.jhb@freebsd.org> References: <201307121650.41701.jhb@freebsd.org> From: Rohit Athavale Date: Fri, 12 Jul 2013 14:10:36 -0700 Message-ID: Subject: Re: ACPI MADT BSP Details To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:12:02 -0000 Thanks John. After reading into details of the ACPI spec, it is also said in the spec that the first processor APIC entry also happens to be the BSP . It is expected the BSP always be kept the first entry in processor APIC's. Best Regards, Rohit *A*thavale On Fri, Jul 12, 2013 at 1:50 PM, John Baldwin wrote: > On Wednesday, July 10, 2013 7:48:42 pm Rohit Athavale wrote: > > Hi Folks, > > > > I have two questions about discovering the processors from the MADT > table. > > > > Firstly, > > Can we find out which processor is the BSP from the MADT tables? > > When comparing the userland mptable binary's output versus acpidump's > > output I noticed that mptable informs us about which processor is the BSP > > and which are AP's . > > However I did not see this in the MADT tables. > > Is there a way to find out which processor is the BSP by means of any of > > the ACPI tables. > > Nope. You can read the local APIC ID of the current CPU during your > bootstrap > though. > > > Secondly, > > Can we write into /dev/mem to say update the contents of MPTable with > > values that are non -default. I plan to read some values from the ACPI > > tables and update the MP tables. > > Is the /dev/mem/ file composed of physical addresses for user space > memory > > ? I know this may not qualify as the correct place to ask,but I guess > acpi > > list might have an answer to this. > > Yes, you can likely do this. > > -- > John Baldwin >