From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 1 02:21:28 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B39FB16A40F; Sun, 1 Oct 2006 02:21:28 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id E969E43D58; Sun, 1 Oct 2006 02:21:25 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.50] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm12.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k912KNi3021200; Sat, 30 Sep 2006 22:20:24 -0400 Message-ID: <451F2620.6030102@root.org> Date: Sat, 30 Sep 2006 19:21:20 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Matteo Riondato References: <20060930123244.GA29307@kaiser.sig11.org> <451EC4E6.7030304@root.org> <20060930221744.GB29307@kaiser.sig11.org> In-Reply-To: <20060930221744.GB29307@kaiser.sig11.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Powerd patch review 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, 01 Oct 2006 02:21:28 -0000 Matteo Riondato wrote: > On Sat, Sep 30, 2006 at 12:26:30PM -0700, Nate Lawson wrote: >> Matteo Riondato wrote: >>> Hi folks, >>> I'm writing you to ask if you could be so kind to review the >>> attached patch to src/usr.sbin/powerd/powerd.c . It should fix the >>> problem descripted in PR bin/97198. I haven't a broken BIOS to test if >>> it really works, but it should. >>> Thanks >>> Best regards >>> P.s. I'm not subscribed to the list, so please CC me. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Index: powerd.c >> I thought this was already fixed and merged in July by Bruno. In any >> case, the right place to fix this is in the cpufreq driver (or >> acpi_perf, where I think this only occurs). See rev 1.21.2.3 of >> acpi_perf.c. > > Yes. PR was filed before that change, which, from my understanding, > solves the issue. Sorry for the noise. > >> Actually, it would be important to see if this is happening in another >> driver. The output of "sysctl dev.cpu" will show all the child drivers >> and settings so we can see if he's using acpi_perf or some other cpufreq >> driver. > > I'll ask the PR submitter. Thanks. > Best regards Also check if 6-stable fixes the problem for him. If so, this issue is closed. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 1 21:22:42 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4029616A412; Sun, 1 Oct 2006 21:22:42 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA10243D77; Sun, 1 Oct 2006 21:22:41 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.50] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm01.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k91LM7Bh017314; Sun, 1 Oct 2006 17:22:07 -0400 Message-ID: <4520319C.2060000@root.org> Date: Sun, 01 Oct 2006 14:22:36 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ariff Abdullah References: <20060929124612.GC4945@poupinou.org> <20060929133747.78185.qmail@web27814.mail.ukl.yahoo.com> <20060929151704.GD4945@poupinou.org> <20060929234407.7d41e633.ariff@FreeBSD.org> In-Reply-To: <20060929234407.7d41e633.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Cy Schubert Subject: Re: Acer Aspire 3620 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, 01 Oct 2006 21:22:42 -0000 Ariff Abdullah wrote: > On Fri, 29 Sep 2006 17:17:04 +0200 > Bruno Ducrot wrote: >> I'm a little bit annoyed by those errors: >> >> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0), >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80), >> AE_NO_HARDWARE_RESPONSE >> >> I think this will break support for battery and maybe thermal zone >> and likely other stuff (though I'm not sure exacly what). >> >> > I guess kern/98171 is worth an attention. That at least fix my > problem on Compaq V3000. > The patch doesn't do what it claims to do. First of all, burst mode does not work right on some systems, which is why I didn't complete implementing it. Even on systems where it works, it seems slower than the default method. So the parts related to burst mode should not be applied unless full support for burst mode is being implemented (i.e. handling hardware-initiated exits from burst mode instead of ignoring them). The part that probably has the actual effect is increasing the time that the system waits for a response. (Try this independent of the burst mode changes to verify). EC_POLL_DELAY is the time between reads of the status register while waiting for a response. But 1 second is a horrible amount of time to have the CPU busy-looping. The default is 10 microseconds. I'd be interested in seeing what other values also work (i.e. 50 us? 100 us?) What about not applying the patch and just increasing the overall timeout period? Set the tunable hw.acpi.ec.poll_timeout to the total number of milliseconds (ms) to wait. Does that fix it? For what values? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 1 21:24:53 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA0EA16A403; Sun, 1 Oct 2006 21:24:53 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id E68F443D76; Sun, 1 Oct 2006 21:24:37 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.50] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm01.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k91LO3I9020134; Sun, 1 Oct 2006 17:24:04 -0400 Message-ID: <45203210.8000201@root.org> Date: Sun, 01 Oct 2006 14:24:32 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cy Schubert References: <20060929124612.GC4945@poupinou.org> <20060929133747.78185.qmail@web27814.mail.ukl.yahoo.com> <20060929151704.GD4945@poupinou.org> <20060929234407.7d41e633.ariff@FreeBSD.org> <4520319C.2060000@root.org> In-Reply-To: <4520319C.2060000@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ariff Abdullah Subject: Re: Acer Aspire 3620 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, 01 Oct 2006 21:24:53 -0000 Nate Lawson wrote: > Ariff Abdullah wrote: >> On Fri, 29 Sep 2006 17:17:04 +0200 >> Bruno Ducrot wrote: >>> I'm a little bit annoyed by those errors: >>> >>> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned >>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >>> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0), >>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >>> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80), >>> AE_NO_HARDWARE_RESPONSE >>> >>> I think this will break support for battery and maybe thermal zone >>> and likely other stuff (though I'm not sure exacly what). >>> >>> >> I guess kern/98171 is worth an attention. That at least fix my >> problem on Compaq V3000. >> Also, thanks for all of you working on this. Forgot to put that in my previous reply. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 1 22:46:54 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC15116A415 for ; Sun, 1 Oct 2006 22:46:53 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8875443D46; Sun, 1 Oct 2006 22:46:53 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k91MkoaJ031600; Sun, 1 Oct 2006 22:46:51 GMT (envelope-from ariff@FreeBSD.org) Date: Mon, 2 Oct 2006 06:45:01 +0800 From: Ariff Abdullah To: Nate Lawson Message-Id: <20061002064501.45105b84.ariff@FreeBSD.org> In-Reply-To: <4520319C.2060000@root.org> References: <20060929124612.GC4945@poupinou.org> <20060929133747.78185.qmail@web27814.mail.ukl.yahoo.com> <20060929151704.GD4945@poupinou.org> <20060929234407.7d41e633.ariff@FreeBSD.org> <4520319C.2060000@root.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e" Cc: freebsd-acpi@FreeBSD.org, Cy.Schubert@spqr.komquats.com Subject: Re: Acer Aspire 3620 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, 01 Oct 2006 22:46:54 -0000 --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 01 Oct 2006 14:22:36 -0700 Nate Lawson wrote: > Ariff Abdullah wrote: > > On Fri, 29 Sep 2006 17:17:04 +0200 > > Bruno Ducrot wrote: > >> I'm a little bit annoyed by those errors: > >> > >> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned > >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution > >> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0), > >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution > >> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80), > >> AE_NO_HARDWARE_RESPONSE > >> > >> I think this will break support for battery and maybe thermal > >zone > and likely other stuff (though I'm not sure exacly what). > >> > >> > > I guess kern/98171 is worth an attention. That at least fix my > > problem on Compaq V3000. > >=20 >=20 > The patch doesn't do what it claims to do. First of all, burst mode >=20 > does not work right on some systems, which is why I didn't complete=20 > implementing it. Even on systems where it works, it seems slower > than the default method. So the parts related to burst mode should > not be applied unless full support for burst mode is being > implemented (i.e. handling hardware-initiated exits from burst mode > instead of ignoring them). >=20 ... which, I agree. > The part that probably has the actual effect is increasing the time > that the system waits for a response. (Try this independent of the > burst mode changes to verify). EC_POLL_DELAY is the time between > reads of the status register while waiting for a response. But 1 > second is a horrible amount of time to have the CPU busy-looping.=20 > The default is 10 microseconds. I'd be interested in seeing what > other values also work (i.e. 50 us? 100 us?) >=20 > What about not applying the patch and just increasing the overall=20 > timeout period? Set the tunable hw.acpi.ec.poll_timeout to the > total number of milliseconds (ms) to wait. Does that fix it? For > what values? >=20 I've just decided to concentrate on this issue. Surpisingly, with just a little hack, everything works smoothly (no more annoying messages, battery status works): --- acpi_ec.c /* * Poll the EC status register for up to 1 ms in chunks of 10 us=20 * to detect completion of the last command. */ +#if 0 for (i =3D 0; i < 1000 / EC_POLL_DELAY; i++) { EcStatus =3D EC_GET_CSR(sc); if (EVENT_READY(Event, EcStatus)) { Status =3D AE_OK; break; } AcpiOsStall(EC_POLL_DELAY); } +#endif period =3D i * EC_POLL_DELAY; --- and that what makes it entering ec_poll_timeout loop below that. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFIETwlr+deMUwTNoRAv2IAKCnNVOJm4ESO69WZqz5hGrNjh/eFACeOuaF va/p75ZbSkWztC6BFEGIGQs= =K1Ub -----END PGP SIGNATURE----- --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e-- From owner-freebsd-acpi@FreeBSD.ORG Sun Oct 1 23:28:22 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8DB416A403; Sun, 1 Oct 2006 23:28:22 +0000 (UTC) (envelope-from Cy.Schubert@spqr.komquats.com) Received: from spqr.osg.gov.bc.ca (spqr.osg.gov.bc.ca [142.32.102.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3909743D49; Sun, 1 Oct 2006 23:28:22 +0000 (GMT) (envelope-from Cy.Schubert@spqr.komquats.com) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by spqr.osg.gov.bc.ca (Postfix) with ESMTP id C4507A2D39; Sun, 1 Oct 2006 16:28:21 -0700 (PDT) Received: from spqr.komquats.com (cwsys9 [10.2.2.1]) by passer.osg.gov.bc.ca (8.13.8/8.12.3) with ESMTP id k91NSmYh008459; Sun, 1 Oct 2006 16:28:48 -0700 (PDT) (envelope-from Cy.Schubert@spqr.komquats.com) Received: from cwsys.cwsent.com (cwsys [10.1.1.1]) by spqr.komquats.com (Postfix) with ESMTP id 049A64C5C5; Sun, 1 Oct 2006 16:28:19 -0700 (PDT) Received: from cwsys (localhost [127.0.0.1]) by cwsys.cwsent.com (8.13.8/8.13.8) with ESMTP id k91NSJmG006722; Sun, 1 Oct 2006 16:28:19 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <200610012328.k91NSJmG006722@cwsys.cwsent.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ariff Abdullah In-Reply-To: Your message of "Mon, 02 Oct 2006 06:45:01 +0800." <20061002064501.45105b84.ariff@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Oct 2006 16:28:18 -0700 Sender: Cy.Schubert@spqr.komquats.com Cc: freebsd-acpi@FreeBSD.org Subject: Re: Acer Aspire 3620 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cy Schubert List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Oct 2006 23:28:22 -0000 In message <20061002064501.45105b84.ariff@FreeBSD.org>, Ariff Abdullah writes: > --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, 01 Oct 2006 14:22:36 -0700 > Nate Lawson wrote: > > Ariff Abdullah wrote: > > > On Fri, 29 Sep 2006 17:17:04 +0200 > > > Bruno Ducrot wrote: > > >> I'm a little bit annoyed by those errors: > > >> > > >> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned > > >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution > > >> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0), > > >> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution > > >> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80), > > >> AE_NO_HARDWARE_RESPONSE > > >> > > >> I think this will break support for battery and maybe thermal > > >zone > and likely other stuff (though I'm not sure exacly what). > > >> > > >> > > > I guess kern/98171 is worth an attention. That at least fix my > > > problem on Compaq V3000. > > >=20 > >=20 > > The patch doesn't do what it claims to do. First of all, burst mode > >=20 > > does not work right on some systems, which is why I didn't complete=20 > > implementing it. Even on systems where it works, it seems slower > > than the default method. So the parts related to burst mode should > > not be applied unless full support for burst mode is being > > implemented (i.e. handling hardware-initiated exits from burst mode > > instead of ignoring them). > >=20 > ... which, I agree. > > > The part that probably has the actual effect is increasing the time > > that the system waits for a response. (Try this independent of the > > burst mode changes to verify). EC_POLL_DELAY is the time between > > reads of the status register while waiting for a response. But 1 > > second is a horrible amount of time to have the CPU busy-looping.=20 > > The default is 10 microseconds. I'd be interested in seeing what > > other values also work (i.e. 50 us? 100 us?) > >=20 > > What about not applying the patch and just increasing the overall=20 > > timeout period? Set the tunable hw.acpi.ec.poll_timeout to the > > total number of milliseconds (ms) to wait. Does that fix it? For > > what values? > >=20 > > I've just decided to concentrate on this issue. Surpisingly, with just > a little hack, everything works smoothly (no more annoying messages, > battery status works): > > --- acpi_ec.c > > /* > * Poll the EC status register for up to 1 ms in chunks of 10 us=20 > * to detect completion of the last command. > */ > +#if 0 > for (i =3D 0; i < 1000 / EC_POLL_DELAY; i++) { > EcStatus =3D EC_GET_CSR(sc); > if (EVENT_READY(Event, EcStatus)) { > Status =3D AE_OK; > break; > } > AcpiOsStall(EC_POLL_DELAY); > } > +#endif > period =3D i * EC_POLL_DELAY; Indeed you will have no more messages and you will not have any way of knowing how much charge your battery has remaining (or the temperature of your motherboard for that matter). My patch in PR/98171 solved my Acer Aspire 3623NWXMi ACPI embedded controller issues. All the patch does is provide some kernel tunables for variables already in the kernel to allow the user to tune (play with) the variables until the messages either stop or are reduced to a tolerable level. The root cause of the messages is a slow embedded controller in the Acer 3620 series laptops, not to mention broken ACPI. My patch allows you to reduce the rate at which acpi_ec.c polls the embedded controller allowing it to slowly recover from the last request made by acpi_ec.c to it. The embedded controller in the Acer 3620 (I have a 3623NWXMi) is unbelievably slow. I reduced the poll interval for my laptop to 1000 ms. The messages are gone, except for one or two thermal zone messages, and bettery level is what the EC reports to FreeBSD and this corresponds to what XP tells me too. The reason the patch doesn't work for some people is that they fail to add the following to /boot/loader.conf: #hw.acpi.ec.poll_timeout=100 #hw.acpi.ec.poll_delay=10 hw.acpi.ec.poll_delay=1000 # hw.acpi.ec.burst=1 I commented out the values I do not use. The hw.acpi.ec.poll_timeout is default at 100 ms. The hw.acpi.ec.poll_delay is default at 10 ms. I set mine to 1000 ms (1 second). The hw.acpi.ec.burst is default 0. Nate has said that this doesn't always work. However if you search the various Linux archives, the Linux ACPI folks tend to use burst mode. In addition to this, they also replace the DSDT. You can find replacement DSDT code at acpi.sourceforge.net, compile it using iasl and load it using acpi_dsdt_load="filename" in /boot/loader.conf. I've tried the 3624NWXMi ACPI code in my 3623 with limited success. The other thing you might want to try is to disassemble your DSDT, fix the bugs in it and recompile it using iasl. I tried this as well until I realised that the root casue of the 3620 EC problems was slow embedded controller hardware, hence the patch. If you use my patch, a bit of tinkering will be required or you could use a sledge hammer like I did and set the poll interval to 1 full second. I doubt the battery charge or the temperature would change that much in the space of a second. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org e**(i*pi)+1=0 From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 00:10:12 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 625B616A403 for ; Mon, 2 Oct 2006 00:10:12 +0000 (UTC) (envelope-from pvizeli@yahoo.de) Received: from web27812.mail.ukl.yahoo.com (web27812.mail.ukl.yahoo.com [217.146.182.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 4BD8543D45 for ; Mon, 2 Oct 2006 00:10:11 +0000 (GMT) (envelope-from pvizeli@yahoo.de) Received: (qmail 25384 invoked by uid 60001); 2 Oct 2006 00:10:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0bfGSX/gEZIlhufYFXRub3HfCPbwxn25coGZH8adslDrIXpXoLciIaTFdzDaZ8T7YGPVBJUX5rQVDG3ZQX769kjsRdCxuQUqyVHnojsDauZHuwTiizS8ISinr3P0gM1ivtAzZwa14FC+VTV4izxHsZkEd00gRzSlRr7ImIVdX9E= ; Message-ID: <20061002001010.25381.qmail@web27812.mail.ukl.yahoo.com> Received: from [213.213.171.7] by web27812.mail.ukl.yahoo.com via HTTP; Mon, 02 Oct 2006 00:10:10 GMT Date: Mon, 2 Oct 2006 00:10:10 +0000 (GMT) From: Vizeli Pascal To: Cy Schubert , Ariff Abdullah In-Reply-To: <200610012328.k91NSJmG006722@cwsys.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-acpi@FreeBSD.org Subject: AW: Acer Aspire 3620 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vizeli Pascal List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 00:10:12 -0000 Thank you for all answer. @Schubert This tipp is verry good. I have do that and think it's work now. I have a 3624NWXMi but with Bios version 1.06 and not with 1.04. I think that is not a problem. You have also a Aspire 3620 series notebook? I have a questen: My Mousepad, Wlan Card and Bluetooth doesn't work. You have a idee why not work that? greet, Pascal From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 00:15:59 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51CB516A412 for ; Mon, 2 Oct 2006 00:15:59 +0000 (UTC) (envelope-from pvizeli@yahoo.de) Received: from web27807.mail.ukl.yahoo.com (web27807.mail.ukl.yahoo.com [217.146.182.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 656EB43D53 for ; Mon, 2 Oct 2006 00:15:58 +0000 (GMT) (envelope-from pvizeli@yahoo.de) Received: (qmail 94756 invoked by uid 60001); 2 Oct 2006 00:15:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=E8fBK14aMb2TkDZeL4A2BkRNMTKg8YG1LAtkzFhYaGR5EsPDjNwDuwlLUN5K529/e+boYQOr6nTdWeo0mhEtl/ExHoU+O0lxo2OYWe08v/7J3+Oi6pYZBH++yU3OZ5qq89wM2cWEVcwB81v2YBC+1W3cmOphuTWbq5LSryP4QAk= ; Message-ID: <20061002001557.94754.qmail@web27807.mail.ukl.yahoo.com> Received: from [213.213.171.7] by web27807.mail.ukl.yahoo.com via HTTP; Mon, 02 Oct 2006 00:15:57 GMT Date: Mon, 2 Oct 2006 00:15:57 +0000 (GMT) From: Vizeli Pascal To: Cy Schubert , Ariff Abdullah In-Reply-To: <200610012328.k91NSJmG006722@cwsys.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-acpi@FreeBSD.org Subject: AW: Acer Aspire 3620 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vizeli Pascal List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 00:15:59 -0000 The new outbut from sysctl -a | grep acpi acpidev 57 2K - 57 32 acpisem 70 5K - 70 64 acpitask 0 0K - 135 32 acpica 1684 90K - 21828 16,32,64,128,256,512,1024,2048 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 0x20041119 debug.acpi.semaphore_debug: 0 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% 0.00% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 59.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 94.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 98.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1.temperature: 50.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 0 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: -1 hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 77.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.battery.life: 97 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1014272 dev.acpi.0.%desc: PTLTD RSDT dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%parent: acpi0 dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x17 dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPCB.EC0_ dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%parent: acpi0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.LPCB.MBD0 dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=1 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%parent: acpi0 dev.acpi_throttle.0.%desc: ACPI CPU Throttling dev.acpi_throttle.0.%driver: acpi_throttle dev.acpi_throttle.0.%parent: cpu0 dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.acpi_lid.0.%desc: Control Method Lid Switch dev.acpi_lid.0.%driver: acpi_lid dev.acpi_lid.0.%location: handle=\_SB_.LID0 dev.acpi_lid.0.%pnpinfo: _HID=PNP0C0D _UID=0 dev.acpi_lid.0.%parent: acpi0 dev.acpi_lid.0.wake: 1 dev.acpi_button.0.%desc: Sleep Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.SLPB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.pcib.0.%parent: acpi0 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.TZS0 dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.acpi_tz.1.%desc: Thermal Zone dev.acpi_tz.1.%driver: acpi_tz dev.acpi_tz.1.%location: handle=\_TZ_.TZS1 dev.acpi_tz.1.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.1.%parent: acpi0 dev.atdma.0.%parent: acpi0 dev.atpic.0.%parent: acpi0 dev.npxisa.0.%parent: acpi0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%parent: acpi0 dev.atkbdc.0.%parent: acpi0 dev.psmcpnp.0.%parent: acpi0 dev.battery.0.%parent: acpi0 dev.acpi_acad.0.%desc: AC Adapter dev.acpi_acad.0.%driver: acpi_acad dev.acpi_acad.0.%location: handle=\_SB_.PCI0.LPCB.EC0_.ADP1 dev.acpi_acad.0.%pnpinfo: _HID=ACPI0003 _UID=0 dev.acpi_acad.0.%parent: acpi0 From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 01:16:33 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 766BC16A416 for ; Mon, 2 Oct 2006 01:16:33 +0000 (UTC) (envelope-from pvizeli@yahoo.de) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B34843D45 for ; Mon, 2 Oct 2006 01:16:32 +0000 (GMT) (envelope-from pvizeli@yahoo.de) Received: (qmail 43518 invoked by uid 60001); 2 Oct 2006 01:16:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=Gj4nx+DlyDvlXkQkUFvyCdjPv6uc6wKpDpXBBdcqQ8fQv3veKZxBaSWjkxu4VnH8LXgPRXStBHL1+ISgDZkIC5v3T/vLo3fKtRmPHLCNp/w6xVVVaT/55C8Jef3y5e3u/TJ6MvhqU0UuvN9oBhpRH2AvdG+1j04fLGUVv12Mujs= ; Message-ID: <20061002011631.43516.qmail@web27801.mail.ukl.yahoo.com> Received: from [213.213.171.7] by web27801.mail.ukl.yahoo.com via HTTP; Mon, 02 Oct 2006 01:16:31 GMT Date: Mon, 2 Oct 2006 01:16:31 +0000 (GMT) From: Vizeli Pascal To: Cy Schubert , Ariff Abdullah MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-acpi@FreeBSD.org Subject: AW: Acer Aspire 3620 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vizeli Pascal List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 01:16:33 -0000 The 1.04 version dosn't work with the 1.06 version. I rewrite that, I hope that ^^''. greet, Pascal From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 05:58:38 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8CDD16A412; Mon, 2 Oct 2006 05:58:38 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77C7243D49; Mon, 2 Oct 2006 05:58:38 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.50] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm15.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id k925wc9F031542; Mon, 2 Oct 2006 01:58:38 -0400 Message-ID: <4520AA88.2080908@root.org> Date: Sun, 01 Oct 2006 22:58:32 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cy Schubert References: <200610012328.k91NSJmG006722@cwsys.cwsent.com> In-Reply-To: <200610012328.k91NSJmG006722@cwsys.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Ariff Abdullah Subject: Re: Acer Aspire 3620 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, 02 Oct 2006 05:58:39 -0000 Cy Schubert wrote: > In message <20061002064501.45105b84.ariff@FreeBSD.org>, Ariff Abdullah > writes: >> --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e >> Content-Type: text/plain; charset=US-ASCII >> Content-Disposition: inline >> Content-Transfer-Encoding: quoted-printable >> >> On Sun, 01 Oct 2006 14:22:36 -0700 >> Nate Lawson wrote: >>> Ariff Abdullah wrote: >>>> On Fri, 29 Sep 2006 17:17:04 +0200 >>>> Bruno Ducrot wrote: >>>>> I'm a little bit annoyed by those errors: >>>>> >>>>> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned >>>>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >>>>> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0), >>>>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution >>>>> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80), >>>>> AE_NO_HARDWARE_RESPONSE >>>>> >>>>> I think this will break support for battery and maybe thermal >>>> zone > and likely other stuff (though I'm not sure exacly what). >>>>> >>>> I guess kern/98171 is worth an attention. That at least fix my >>>> problem on Compaq V3000. >>>> =20 >>> =20 >>> The patch doesn't do what it claims to do. First of all, burst mode >>> =20 >>> does not work right on some systems, which is why I didn't complete=20 >>> implementing it. Even on systems where it works, it seems slower >>> than the default method. So the parts related to burst mode should >>> not be applied unless full support for burst mode is being >>> implemented (i.e. handling hardware-initiated exits from burst mode >>> instead of ignoring them). >>> =20 >> ... which, I agree. >> >>> The part that probably has the actual effect is increasing the time >>> that the system waits for a response. (Try this independent of the >>> burst mode changes to verify). EC_POLL_DELAY is the time between >>> reads of the status register while waiting for a response. But 1 >>> second is a horrible amount of time to have the CPU busy-looping.=20 >>> The default is 10 microseconds. I'd be interested in seeing what >>> other values also work (i.e. 50 us? 100 us?) >>> =20 >>> What about not applying the patch and just increasing the overall=20 >>> timeout period? Set the tunable hw.acpi.ec.poll_timeout to the >>> total number of milliseconds (ms) to wait. Does that fix it? For >>> what values? >>> =20 >> I've just decided to concentrate on this issue. Surpisingly, with just >> a little hack, everything works smoothly (no more annoying messages, >> battery status works): >> >> --- acpi_ec.c >> >> /* >> * Poll the EC status register for up to 1 ms in chunks of 10 us=20 >> * to detect completion of the last command. >> */ >> +#if 0 >> for (i =3D 0; i < 1000 / EC_POLL_DELAY; i++) { >> EcStatus =3D EC_GET_CSR(sc); >> if (EVENT_READY(Event, EcStatus)) { >> Status =3D AE_OK; >> break; >> } >> AcpiOsStall(EC_POLL_DELAY); >> } >> +#endif >> period =3D i * EC_POLL_DELAY; > > Indeed you will have no more messages and you will not have any way of knowing how much charge your battery has remaining (or the temperature of your motherboard for that matter). He says that battery status works after his patch. This still needs more isolation. Does increasing EC_POLL_DELAY from 10 to 100 help? Does moving AcpiOsStall() before the first read (EC_GET_CSR) work? > My patch in PR/98171 solved my Acer Aspire 3623NWXMi ACPI embedded controller issues. All the patch does is provide some kernel tunables for variables already in the kernel to allow the user to tune (play with) the variables until the messages either stop or are reduced to a tolerable level. The root cause of the messages is a slow embedded controller in the Acer 3620 series laptops, not to mention broken ACPI. My patch allows you to reduce the rate at which acpi_ec.c polls the embedded controller allowing it to slowly recover from the last request made by acpi_ec.c to it. The embedded controller in the Acer 3620 (I have a 3623NWXMi) is unbelievably slow. I reduced the poll interval for my laptop to 1000 ms. The messages are gone, except for one or two thermal zone messages, and bettery level is what the EC reports to FreeBSD and this corresponds to what XP tells me too. > > The reason the patch doesn't work for some people is that they fail to add the following to /boot/loader.conf: > > #hw.acpi.ec.poll_timeout=100 > #hw.acpi.ec.poll_delay=10 > hw.acpi.ec.poll_delay=1000 > # hw.acpi.ec.burst=1 > > I commented out the values I do not use. The hw.acpi.ec.poll_timeout is default at 100 ms. The hw.acpi.ec.poll_delay is default at 10 ms. I set mine to 1000 ms (1 second). The hw.acpi.ec.burst is default 0. Nate has said that this doesn't always work. However if you search the various Linux archives, the Linux ACPI folks tend to use burst mode. In addition to this, they also replace the DSDT. You can find replacement DSDT code at acpi.sourceforge.net, compile it using iasl and load it using acpi_dsdt_load="filename" in /boot/loader.conf. I've tried the 3624NWXMi ACPI code in my 3623 with limited success. Your ec_poll_delay (and EC_POLL_DELAY) is in units of microseconds (us), not milliseconds (ms). The default poll delay is 10 microseconds between reads of the command/status register. The default total timeout (poll_timeout) is 100 milliseconds. I'm interested in one or more of you trying to isolate this more. Is the problem the first read (EC_GET_CSR) happening too quickly on some systems? Or is it that polling every 10 microseconds is too often? At what exact threshold does it start to work for your system? Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 08:34:26 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F70616A403; Mon, 2 Oct 2006 08:34:26 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC40143D49; Mon, 2 Oct 2006 08:34:25 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1GUJFj-0003jO-00; Mon, 02 Oct 2006 10:34:19 +0200 Date: Mon, 2 Oct 2006 10:34:19 +0200 To: Vizeli Pascal Message-ID: <20061002083419.GE4945@poupinou.org> References: <200610012328.k91NSJmG006722@cwsys.cwsent.com> <20061002001010.25381.qmail@web27812.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061002001010.25381.qmail@web27812.mail.ukl.yahoo.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-acpi@FreeBSD.org, Ariff Abdullah , Cy Schubert Subject: Re: Acer Aspire 3620 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, 02 Oct 2006 08:34:26 -0000 On Mon, Oct 02, 2006 at 12:10:10AM +0000, Vizeli Pascal wrote: > Thank you for all answer. > > @Schubert > This tipp is verry good. I have do that and think it's work now. Just do a acpiconf -i 0 both on AC and on battery to check if that's work. > I have a 3624NWXMi but with Bios version 1.06 and not with 1.04. I think that is not a problem. > > You have also a Aspire 3620 series notebook? > I have a questen: > My Mousepad, Wlan Card and Bluetooth doesn't work. > You have a idee why not work that? > For wlan card (and maybe bluetooth) this will require a specific driver I'm afraid. I've seen some work on that matter under linux but for older Acer laptops, though. I don't understand ATM the mousepad problem you have. Do you mean it doesn't work at all or you don't get the extra feature associated to it? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 11:08:08 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A34016A403 for ; Mon, 2 Oct 2006 11:08:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2FB443D5A for ; Mon, 2 Oct 2006 11:08:07 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k92B87L7001386 for ; Mon, 2 Oct 2006 11:08:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k92B86Q9001382 for freebsd-acpi@FreeBSD.org; Mon, 2 Oct 2006 11:08:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Oct 2006 11:08:06 GMT Message-Id: <200610021108.k92B86Q9001382@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 02 Oct 2006 11:08:08 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/55822 acpi No ACPI power off with SMP kernel o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/64002 acpi acpi problem o i386/67273 acpi [hang] system hangs with acpi and Xfree o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o i386/80426 acpi [APIC] [panic] 5.4-RC3 still panic when boot on ASUS P o i386/87568 acpi [ACPI] [REGRESSION] 6.0-STABLE needs ACPI disabled but 11 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/73822 acpi [request] add thermal support to ACPI o kern/73823 acpi [feature request] acpi / power-on by timer support f kern/74030 acpi Unplugging AC causes battery % to stay locked at 98% f kern/90871 acpi ACPI problems with ASUS A8N-VM-CSM o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att 9 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 14:51:39 2006 Return-Path: X-Original-To: freebsd-acpi@FreeBSD.org Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FCA416A412 for ; Mon, 2 Oct 2006 14:51:39 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C54B43D49; Mon, 2 Oct 2006 14:51:39 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k92Epa8p025786; Mon, 2 Oct 2006 14:51:37 GMT (envelope-from ariff@FreeBSD.org) Date: Mon, 2 Oct 2006 22:49:45 +0800 From: Ariff Abdullah To: Nate Lawson Message-Id: <20061002224945.4cb4c605.ariff@FreeBSD.org> In-Reply-To: <4520AA88.2080908@root.org> References: <200610012328.k91NSJmG006722@cwsys.cwsent.com> <4520AA88.2080908@root.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi" Cc: freebsd-acpi@FreeBSD.org, Cy.Schubert@spqr.komquats.com Subject: Re: Acer Aspire 3620 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, 02 Oct 2006 14:51:39 -0000 --Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 01 Oct 2006 22:58:32 -0700 Nate Lawson wrote: >=20 > He says that battery status works after his patch. This still needs > This "battery status works" probably need a reintepretation. First, let me remind you guys about this: http://lists.freebsd.org/mailman/htdig/freebsd-acpi/2006-January/002416.html I have 3 laptops (not mine), and luckily each behaves differently 1) Acer Ferrari 4k Here, everything works great after patching the dsdt to resolve "Z00N" issue. Battery status works perfect and report _BOTH_ "Remaining capacity:" _and_ "Remaining time". # sysctl hw.acpi.battery hw.acpi.battery.life: 98 <- I guess % of capacity hw.acpi.battery.time: 120 <- minutes hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 2) Compaq Presario M2000 Things becoming interesting here. At first, I thought there is no way to find out the battery status just because both sysctl hw.acpi.battery and acpiconf return invalid value/error. Digging through the sources, and I realize that both of them set a strict requirement for battery status to return proper "Remaining time" and simply bail out just because it can't find any. Nevertheless, my patch for acpiconf.c is at least let it be more forgiving about this. Even on Windows/Linux, they do not try hard to calculate "Remaining Time" if it seems impossible and just satisfied with "Remaining Capacity". # sysctl hw.acpi.battery hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 3) Compaq Presario V3000 Simmilar problem with #2. Solved after the acpi_ec.c hack. Strange thing is, even this laptop does not support "Remaining time", yet the battery status works even without patching acpiconf.c # sysctl hw.acpi.battery hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 There is indeed a considerable delay while running sysctl caused by tsleep() loop, which makes the battery status works. Something to do with _BIF or _BST, I guess. > more isolation. Does increasing EC_POLL_DELAY from 10 to 100 help?=20 > Does moving AcpiOsStall() before the first read (EC_GET_CSR) work? >=20 Doesn't help. > > My patch in PR/98171 solved my Acer Aspire 3623NWXMi ACPI embedded > > controller issues. All the patch does is provide some kernel > > tunables for variables already in the kernel to allow the user to > > tune (play with) the variables until the messages either stop or > > are reduced to a tolerable level. The root cause of the messages > > is a slow embedded controller in the Acer 3620 series laptops, not > > to mention broken ACPI. My patch allows you to reduce the rate at > > which acpi_ec.c polls the embedded controller allowing it to > > slowly recover from the last request made by acpi_ec.c to it. The > > embedded controller in the Acer 3620 (I have a 3623NWXMi) is > > unbelievably slow. I reduced the poll interval for my laptop to > > 1000 ms. The messages are gone, except for one or two thermal zone > > messages, and bettery level is what the EC reports to FreeBSD and > > this corresponds to what XP tells me too. > >=20 > > The reason the patch doesn't work for some people is that they > > fail to add the following to /boot/loader.conf: > >=20 > > #hw.acpi.ec.poll_timeout=3D100 > > #hw.acpi.ec.poll_delay=3D10 > > hw.acpi.ec.poll_delay=3D1000 > > # hw.acpi.ec.burst=3D1 > >=20 > > I commented out the values I do not use. The > > hw.acpi.ec.poll_timeout is default at 100 ms. The > > hw.acpi.ec.poll_delay is default at 10 ms. I set mine to 1000 ms > > (1 second). The hw.acpi.ec.burst is default 0. Nate has said that > > this doesn't always work. However if you search the various Linux > > archives, the Linux ACPI folks tend to use burst mode. In > > addition to this, they also replace the DSDT. You can find > > replacement DSDT code at acpi.sourceforge.net, compile it using > > iasl and load it using acpi_dsdt_load=3D"filename" in > > /boot/loader.conf. I've tried the 3624NWXMi ACPI code in my 3623 > > with limited success. >=20 > Your ec_poll_delay (and EC_POLL_DELAY) is in units of microseconds > (us), not milliseconds (ms). The default poll delay is 10 > microseconds between reads of the command/status register. The > default total timeout (poll_timeout) is 100 milliseconds. >=20 > I'm interested in one or more of you trying to isolate this more.=20 > Is the problem the first read (EC_GET_CSR) happening too quickly on > some systems? Or is it that polling every 10 microseconds is too > often? At what exact threshold does it start to work for your > system? >=20 I'm a bit busy with snd_hda(4), but I'll tag along. > Thanks, > --=20 > Nate >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFIScNlr+deMUwTNoRAmfVAJkBT5ebFtqqDXDX0ITY8zb/I3CGjgCg0+Mg B3x0dfxGUtwTKnnBofl2u9A= =iSLT -----END PGP SIGNATURE----- --Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi-- From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 19:22:01 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D028716A416; Mon, 2 Oct 2006 19:22:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B7843D53; Mon, 2 Oct 2006 19:21:58 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k92JLmp6018637; Mon, 2 Oct 2006 15:21:50 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andrea Bittau Date: Mon, 2 Oct 2006 14:24:18 -0400 User-Agent: KMail/1.9.1 References: <20060921000628.GA1832@shorty.sorbonet.org> In-Reply-To: <20060921000628.GA1832@shorty.sorbonet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610021424.18562.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Oct 2006 15:21:50 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1973/Mon Oct 2 11:18:33 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 02 Oct 2006 19:22:01 -0000 On Wednesday 20 September 2006 20:06, Andrea Bittau wrote: > This is a half working hack for getting suspend/resume to "work" on an IBM > > ... > > 2) apic. FreeBSD reconfigures the io apic upon resume, but not the local apic. > The patch attached to this mail fixes this. Indeed, it almost does so in the > "proper" way and not so much of a hack =D. I actually have made a full patch for APIC I think (thanks for your work as it reminded me about needing to resume lapic). You can find it at http://www.FreeBSD.org/~jhb/patches/apic_resume.patch It changes the x86 interrupt code to resume interrupt controllers, not interrupt sources. It then uses this to make sure the 8259A PICs are properly reset on resume as well as resuming the local APIC. Can you test this w/o SMP and make sure it works? > 3) SMP. The second core needs to be killed and woken up as appropriate. The > way I do this is quite lame. > - Force the second core in the idle loop by setting machdep.hlt_cpus=2. > - make system look like UP instead of SMP [i.e. deactivate SMP] & suspend. > - resume, wake up other core [which will run idle process] and activate SMP. Probably we need to get onto the BSP via sched_bind() during suspend and then stop the other CPUs using stop_cpus(). The hard part, however, is properly resuming the darn things. Do you know what mode the CPUs come back up in? It looks like we need to resend startup IPIs to them from your patch. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 22:03:15 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CADF016A40F; Mon, 2 Oct 2006 22:03:15 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D63F43D55; Mon, 2 Oct 2006 22:03:13 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [67.119.74.222] Received: from [10.0.0.44] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by ylpvm15.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id k92M39cG003075; Mon, 2 Oct 2006 18:03:10 -0400 Message-ID: <45218C97.5050802@root.org> Date: Mon, 02 Oct 2006 15:03:03 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Baldwin References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> In-Reply-To: <200610021424.18562.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Andrea Bittau , freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 02 Oct 2006 22:03:15 -0000 John Baldwin wrote: > On Wednesday 20 September 2006 20:06, Andrea Bittau wrote: >> This is a half working hack for getting suspend/resume to "work" on an IBM >> >> ... >> >> 2) apic. FreeBSD reconfigures the io apic upon resume, but not the local > apic. >> The patch attached to this mail fixes this. Indeed, it almost does so in > the >> "proper" way and not so much of a hack =D. > > I actually have made a full patch for APIC I think (thanks for your work as it > reminded me about needing to resume lapic). You can find it at > http://www.FreeBSD.org/~jhb/patches/apic_resume.patch It changes the x86 > interrupt code to resume interrupt controllers, not interrupt sources. It > then uses this to make sure the 8259A PICs are properly reset on resume as > well as resuming the local APIC. Can you test this w/o SMP and make sure it > works? Great to see this work going on. I just got a Core Duo laptop so this would be great to see fixed. I'm kinda disappointed you're not using newbus for your device methods, but I think I mentioned that before. On the reset code, shouldn't there be some delays between writes to the registers? + outb(IO_ICU1, ICW1_RESET | ICW1_IC4); + outb(IO_ICU1 + ICU_IMR_OFFSET, IDT_IO_INTS); [delay?] + outb(IO_ICU1 + ICU_IMR_OFFSET, 1 << 2); [delay?] + outb(IO_ICU1 + ICU_IMR_OFFSET, ICW4_8086); [delay?] + outb(IO_ICU1 + ICU_IMR_OFFSET, 0xff); + outb(IO_ICU1, OCW3_SEL | OCW3_RR); + + outb(IO_ICU2, ICW1_RESET | ICW1_IC4); + outb(IO_ICU2 + ICU_IMR_OFFSET, IDT_IO_INTS + 8); [delay?] + outb(IO_ICU2 + ICU_IMR_OFFSET, 2); [delay?] + outb(IO_ICU2 + ICU_IMR_OFFSET, ICW4_8086); [delay?] + outb(IO_ICU2 + ICU_IMR_OFFSET, 0xff); + outb(IO_ICU2, OCW3_SEL | OCW3_RR); >> 3) SMP. The second core needs to be killed and woken up as appropriate. > The >> way I do this is quite lame. >> - Force the second core in the idle loop by setting machdep.hlt_cpus=2. >> - make system look like UP instead of SMP [i.e. deactivate SMP] & > suspend. >> - resume, wake up other core [which will run idle process] and activate > SMP. > > Probably we need to get onto the BSP via sched_bind() during suspend and then > stop the other CPUs using stop_cpus(). The hard part, however, is properly > resuming the darn things. Do you know what mode the CPUs come back up in? > It looks like we need to resend startup IPIs to them from your patch. The writes to the PM registers should happen from the BSP anyway, so sched_bind() is the right way to go. I think you need to start them up the same as boot, including startup IPI and then enabling scheduling on them. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 2 22:31:11 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D3B216A407; Mon, 2 Oct 2006 22:31:11 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: from darkircop.org (tapir.cs.ucl.ac.uk [128.16.66.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id C547643D4C; Mon, 2 Oct 2006 22:31:10 +0000 (GMT) (envelope-from a.bittau@cs.ucl.ac.uk) Received: by darkircop.org (Postfix, from userid 0) id 6DB3A5C5C71; Mon, 2 Oct 2006 23:30:55 +0100 (BST) Date: Mon, 2 Oct 2006 23:30:55 +0100 From: Andrea Bittau To: John Baldwin Message-ID: <20061002223055.GA8217@shorty.sorbonet.org> References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610021424.18562.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Echelon: Bush Bomb War KGB Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 02 Oct 2006 22:31:11 -0000 On Mon, Oct 02, 2006 at 02:24:18PM -0400, John Baldwin wrote: > well as resuming the local APIC. Can you test this w/o SMP and make sure it > works? I'll give it a shot as soon as I get some time. > Probably we need to get onto the BSP via sched_bind() during suspend and then > stop the other CPUs using stop_cpus(). The hard part, however, is properly Yea I do that in acpi_SetSleepState(). Essentially I copied the shutdown code. > resuming the darn things. Do you know what mode the CPUs come back up in? > It looks like we need to resend startup IPIs to them from your patch. Yea it all comes back in real mode. I've tried using the standard freebsd "boot code" for waking up the second CPU. There were some issues with the BSP not using PTD_Idle. I don't know enough about computers and freebsd to know what exactly that means. Also, when the second CPU came back, if it entered the scheduler, it would die, so I had to leave it in the idle loop by setting the cpu_hlt mask. Anyway, the correct way to do it I think is to generalize the save state & wakeup code used by the BSP in acpi_sleep_machdep(). That is, the second core should save its state and wake up the same way as the BSP does. It should not use the "come to life mechanism" used at boot-time. The reason is that the memory is setup properly and the second core should have saved registers which make sense so less "initialization and setup" needs to be performed. From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 00:30:08 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2933916A412; Tue, 3 Oct 2006 00:30:08 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E91743D46; Tue, 3 Oct 2006 00:30:07 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [67.119.74.222] Received: from [10.0.0.44] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by ylpvm01.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k930TS1Q015985; Mon, 2 Oct 2006 20:29:29 -0400 Message-ID: <4521AF05.50208@root.org> Date: Mon, 02 Oct 2006 17:29:57 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrea Bittau References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org> In-Reply-To: <20061002223055.GA8217@shorty.sorbonet.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 00:30:08 -0000 Andrea Bittau wrote: > On Mon, Oct 02, 2006 at 02:24:18PM -0400, John Baldwin wrote: >> well as resuming the local APIC. Can you test this w/o SMP and make sure it >> works? > > I'll give it a shot as soon as I get some time. > >> Probably we need to get onto the BSP via sched_bind() during suspend and then >> stop the other CPUs using stop_cpus(). The hard part, however, is properly > > Yea I do that in acpi_SetSleepState(). Essentially I copied the shutdown code. > >> resuming the darn things. Do you know what mode the CPUs come back up in? >> It looks like we need to resend startup IPIs to them from your patch. > > Yea it all comes back in real mode. I've tried using the standard freebsd "boot > code" for waking up the second CPU. There were some issues with the BSP not > using PTD_Idle. I don't know enough about computers and freebsd to know what > exactly that means. Also, when the second CPU came back, if it entered the > scheduler, it would die, so I had to leave it in the idle loop by setting the > cpu_hlt mask. > > Anyway, the correct way to do it I think is to generalize the save state & > wakeup code used by the BSP in acpi_sleep_machdep(). That is, the second core > should save its state and wake up the same way as the BSP does. It should not > use the "come to life mechanism" used at boot-time. The reason is that the > memory is setup properly and the second core should have saved registers which > make sense so less "initialization and setup" needs to be performed. I disagree. Instead of trying to capture all that register state, including MSRs, MTRRs, etc., it seems easier just to reinitialize from scratch. We'll need to do that anyway once suspend-to-disk is implemented since that kind of resume is equivalent to a hard power cycle. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 06:52:54 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F0516A40F for ; Tue, 3 Oct 2006 06:52:54 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C72443D77 for ; Tue, 3 Oct 2006 06:52:47 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([81.18.142.225]:51729 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S2078125AbWJCGwg (ORCPT ); Tue, 3 Oct 2006 10:52:36 +0400 X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as: bu7cher Message-ID: <452208B0.7030604@yandex.ru> Date: Tue, 03 Oct 2006 10:52:32 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: ACPI problems with Maxselect GT3000 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, 03 Oct 2006 06:52:54 -0000 Hi, I've tried to solve some ACPI problems with my notebook.(dmesg: http://butcher.heavennet.ru/acpi/) I have these messages: Oct 2 17:58:06 btr-nb kernel: ACPI-0448: *** Error: Looking up [\_SB_.ADP0] in namespace, AE_NOT_FOUND Oct 2 17:58:06 btr-nb kernel: SearchNode 0xc26889a0 StartNode 0xc26889a0 ReturnNode 0 Oct 2 17:58:06 btr-nb kernel: ACPI-0610: *** Error: Method execution failed [\_SB_.PCI0.EC__._Q16] (Node 0xc26889a0), AE_NOT_FOUND Oct 2 17:58:16 btr-nb kernel: acpi_tz0: _CRT value is absurd, ignored (154.8C) ASL hacking have some results, but i don't know that it's correct. My patch: --- maxselect-gt3000.asl.orig Mon Oct 2 23:11:47 2006 +++ patched/maxselect-gt3000.asl Mon Oct 2 23:11:47 2006 @@ -211,6 +211,7 @@ Store (0x83, \_SB.BCMD) Store (0x83, \_SB.SMIC) } + Return (Zero) } Scope (\_PR) @@ -1390,7 +1391,7 @@ ) }) OperationRegion (RAM, EmbeddedControl, 0x00, 0xFF) - Field (RAM, AnyAcc, Lock, Preserve) + Field (RAM, ByteAcc, Lock, Preserve) { NMSG, 8, SLED, 4, @@ -1489,13 +1490,13 @@ Method (_Q16, 0, NotSerialized) { Store (0x16, DBUG) - Notify (\_SB.ADP0, 0x80) - If (\_SB.PCI0.LPC0.EC.BAT0) + Notify (\_SB.BAT0, 0x80) + If (\_SB.PCI0.EC.ADP) { Notify (\_SB.BAT0, 0x80) } - \POWC + /* \POWC */ } Method (_Q17, 0, NotSerialized) @@ -4128,14 +4129,16 @@ Method (_PSV, 0, NotSerialized) { - Multiply (0x64, 0x0A, Local0) + /* 30 C */ + Multiply (0x1e, 0x0A, Local0) Add (Local0, 0x0AAA, Local0) Return (Local0) } Method (_AC0, 0, NotSerialized) { - Return (0x0D66) + /* 65 C */ + Return (0x0D34) } Name (_PSL, Package (0x01) @@ -4144,7 +4147,8 @@ }) Method (_CRT, 0, NotSerialized) { - Multiply (0x9B, 0x0A, Local0) + /* 80 C */ + Multiply (0x51, 0x0A, Local0) Add (Local0, 0x0AAA, Local0) Return (Local0) } @@ -4439,13 +4443,13 @@ 0x000005C0 } }) + /* Zero Zero Zero Zero Zero Zero - Zero - Zero + Zero */ } } -- WBR, Andrey V. Elsukov From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 07:21:01 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0428316A407; Tue, 3 Oct 2006 07:21:01 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: from darkircop.org (tapir.cs.ucl.ac.uk [128.16.66.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8572B43D5A; Tue, 3 Oct 2006 07:21:00 +0000 (GMT) (envelope-from a.bittau@cs.ucl.ac.uk) Received: by darkircop.org (Postfix, from userid 0) id 131DD5C5C6E; Tue, 3 Oct 2006 08:20:45 +0100 (BST) Date: Tue, 3 Oct 2006 08:20:45 +0100 From: Andrea Bittau To: Nate Lawson Message-ID: <20061003072044.GA9182@shorty.sorbonet.org> References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org> <4521AF05.50208@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4521AF05.50208@root.org> User-Agent: Mutt/1.4.2.1i X-Echelon: Bush Bomb War KGB Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 07:21:01 -0000 On Mon, Oct 02, 2006 at 05:29:57PM -0700, Nate Lawson wrote: > I disagree. Instead of trying to capture all that register state, > including MSRs, MTRRs, etc., it seems easier just to reinitialize from > scratch. We'll need to do that anyway once suspend-to-disk is > implemented since that kind of resume is equivalent to a hard power cycle. OK so what's the protocol? Force the second CPU into the idle loop, boot it up, and let the scheduler decide what it should run? I tried doing that. It sort of works but the system seemed unstable [page faults] when interrupts were handled by the second core, or some processes were run. One thing I noted is that the CR3 was different from what it was previously. On wakeup, it's idle_ptd and i'm not sure what that means and if that's ok. Also, I don't see how reinitializing from scratch is "easier". You'd have to setup all registers anyway. Furthermore, you'd have to allocate a stack, the per-cpu pages and stuff like that which is already in RAM. [If you use the existing values then it's not "reinitializing from scratch ;D.] Anyway, I don't want to argue because I know really little of this stuff---I just wanted to give a shot at getting s/r working on my laptop ;D I got it ~75% working on my laptop. Now I'm waiting for someone to point out how to wakeup the second core properly and why my mechanism [albeit being a hack] doesn't work. From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 17:33:09 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1BAB16A416; Tue, 3 Oct 2006 17:33:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAA2343D45; Tue, 3 Oct 2006 17:33:08 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k93HWtOa027369; Tue, 3 Oct 2006 13:32:59 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Tue, 3 Oct 2006 13:00:48 -0400 User-Agent: KMail/1.9.1 References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <45218C97.5050802@root.org> In-Reply-To: <45218C97.5050802@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610031300.49509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 03 Oct 2006 13:33:00 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1987/Tue Oct 3 11:45:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, Andrea Bittau , freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 17:33:10 -0000 On Monday 02 October 2006 18:03, Nate Lawson wrote: > John Baldwin wrote: > > On Wednesday 20 September 2006 20:06, Andrea Bittau wrote: > >> This is a half working hack for getting suspend/resume to "work" on an IBM > >> > >> ... > >> > >> 2) apic. FreeBSD reconfigures the io apic upon resume, but not the local > > apic. > >> The patch attached to this mail fixes this. Indeed, it almost does so in > > the > >> "proper" way and not so much of a hack =D. > > > > I actually have made a full patch for APIC I think (thanks for your work as it > > reminded me about needing to resume lapic). You can find it at > > http://www.FreeBSD.org/~jhb/patches/apic_resume.patch It changes the x86 > > interrupt code to resume interrupt controllers, not interrupt sources. It > > then uses this to make sure the 8259A PICs are properly reset on resume as > > well as resuming the local APIC. Can you test this w/o SMP and make sure it > > works? > > Great to see this work going on. I just got a Core Duo laptop so this > would be great to see fixed. > > I'm kinda disappointed you're not using newbus for your device methods, > but I think I mentioned that before. I'll do that once we have multi-pass device probing, but for now we need to make sure interrupts are working before we start resuming other devices. > On the reset code, shouldn't there be some delays between writes to the > registers? > > + outb(IO_ICU1, ICW1_RESET | ICW1_IC4); > + outb(IO_ICU1 + ICU_IMR_OFFSET, IDT_IO_INTS); > [delay?] > + outb(IO_ICU1 + ICU_IMR_OFFSET, 1 << 2); > [delay?] > + outb(IO_ICU1 + ICU_IMR_OFFSET, ICW4_8086); > [delay?] > + outb(IO_ICU1 + ICU_IMR_OFFSET, 0xff); > + outb(IO_ICU1, OCW3_SEL | OCW3_RR); > + > + outb(IO_ICU2, ICW1_RESET | ICW1_IC4); > + outb(IO_ICU2 + ICU_IMR_OFFSET, IDT_IO_INTS + 8); > [delay?] > + outb(IO_ICU2 + ICU_IMR_OFFSET, 2); > [delay?] > + outb(IO_ICU2 + ICU_IMR_OFFSET, ICW4_8086); > [delay?] > + outb(IO_ICU2 + ICU_IMR_OFFSET, 0xff); > + outb(IO_ICU2, OCW3_SEL | OCW3_RR); Note that I just ripped this code out from amd64/amd64/machdep.c where there are no delays. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 17:33:14 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F11A716A4EA; Tue, 3 Oct 2006 17:33:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4234E43D45; Tue, 3 Oct 2006 17:33:14 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k93HWtOb027369; Tue, 3 Oct 2006 13:33:02 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andrea Bittau Date: Tue, 3 Oct 2006 13:02:34 -0400 User-Agent: KMail/1.9.1 References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org> In-Reply-To: <20061002223055.GA8217@shorty.sorbonet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610031302.34835.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 03 Oct 2006 13:33:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1987/Tue Oct 3 11:45:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 17:33:15 -0000 On Monday 02 October 2006 18:30, Andrea Bittau wrote: > > resuming the darn things. Do you know what mode the CPUs come back up in? > > It looks like we need to resend startup IPIs to them from your patch. > > Yea it all comes back in real mode. I've tried using the standard freebsd "boot > code" for waking up the second CPU. There were some issues with the BSP not > using PTD_Idle. I don't know enough about computers and freebsd to know what > exactly that means. Also, when the second CPU came back, if it entered the > scheduler, it would die, so I had to leave it in the idle loop by setting the > cpu_hlt mask. > > Anyway, the correct way to do it I think is to generalize the save state & > wakeup code used by the BSP in acpi_sleep_machdep(). That is, the second core > should save its state and wake up the same way as the BSP does. It should not > use the "come to life mechanism" used at boot-time. The reason is that the > memory is setup properly and the second core should have saved registers which > make sense so less "initialization and setup" needs to be performed. No, the CPUs are going to come back into real mode, so we will need to bootstrap them back into the kernel, etc. Once you've done that you can make sure of stoppcbs[] (assuming you use stop_cpus to shut them down) to restore enough state to get them back into the threads they were in when the suspend happened. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 21:03:46 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6238F16A412; Tue, 3 Oct 2006 21:03:46 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7765E43D7E; Tue, 3 Oct 2006 21:03:36 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [67.119.74.222] Received: from [10.0.0.44] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by ylpvm29.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k93L2WOB022442; Tue, 3 Oct 2006 17:02:32 -0400 Message-ID: <4522D023.9090501@root.org> Date: Tue, 03 Oct 2006 14:03:31 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: John Baldwin References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org> <200610031302.34835.jhb@freebsd.org> In-Reply-To: <200610031302.34835.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Andrea Bittau , freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 21:03:46 -0000 John Baldwin wrote: > On Monday 02 October 2006 18:30, Andrea Bittau wrote: >>> resuming the darn things. Do you know what mode the CPUs come back up in? >>> It looks like we need to resend startup IPIs to them from your patch. >> Yea it all comes back in real mode. I've tried using the standard > freebsd "boot >> code" for waking up the second CPU. There were some issues with the BSP not >> using PTD_Idle. I don't know enough about computers and freebsd to know > what >> exactly that means. Also, when the second CPU came back, if it entered the >> scheduler, it would die, so I had to leave it in the idle loop by setting > the >> cpu_hlt mask. >> >> Anyway, the correct way to do it I think is to generalize the save state & >> wakeup code used by the BSP in acpi_sleep_machdep(). That is, the second > core >> should save its state and wake up the same way as the BSP does. It should > not >> use the "come to life mechanism" used at boot-time. The reason is that the >> memory is setup properly and the second core should have saved registers > which >> make sense so less "initialization and setup" needs to be performed. > > No, the CPUs are going to come back into real mode, so we will need to > bootstrap them back into the kernel, etc. Once you've done that you can make > sure of stoppcbs[] (assuming you use stop_cpus to shut them down) to restore > enough state to get them back into the threads they were in when the suspend > happened. > I agree. The standard switch to protected mode, paging, etc. needs to be performed and then resume from the saved register context. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 3 21:34:13 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88B4F16A412; Tue, 3 Oct 2006 21:34:13 +0000 (UTC) (envelope-from a.bittau@cs.ucl.ac.uk) Received: from darkircop.org (tapir.cs.ucl.ac.uk [128.16.66.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEB4343D69; Tue, 3 Oct 2006 21:34:12 +0000 (GMT) (envelope-from a.bittau@cs.ucl.ac.uk) Received: by darkircop.org (Postfix, from userid 0) id D14985C5CC2; Tue, 3 Oct 2006 22:33:56 +0100 (BST) Date: Tue, 3 Oct 2006 22:33:56 +0100 From: Andrea Bittau To: Nate Lawson Message-ID: <20061003213356.GA6149@shorty.sorbonet.org> References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org> <200610031302.34835.jhb@freebsd.org> <4522D023.9090501@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4522D023.9090501@root.org> User-Agent: Mutt/1.4.2.1i X-Echelon: Bush Bomb War KGB Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 03 Oct 2006 21:34:13 -0000 On Tue, Oct 03, 2006 at 02:03:31PM -0700, Nate Lawson wrote: > I agree. The standard switch to protected mode, paging, etc. needs to > be performed and then resume from the saved register context. I guess my point was that there are two pieces of code that do that: 1) mpboot.s bootMP() used by system bootstrap and what my current patch uses. I think this is what you guys are suggesting to use, and I'm doing it anyway in my patch, but I just want to be the devil's advocate =D. 2) acpi_wakecode.S wakeup_16() used by the BSP to wake itself up. This is what I was suggesting should be generalized and used by the other cores too. The difference of this code as opposed to #1 is that #2 can "cheat". That is, we can create the code for #2 on the fly and do stuff like mov old_eax,eax etc and don't have to be smart about figuring out where the CPU should land and how it should initialize itself [as in the case of #1]. I'm just wondering whether we should do something about the assembly "code duplication" in #1 and #2. I understand they serve a different purpose, but arguably, they do the same thing: real-mode -> jump in kernel. What is different is what happens once in kernel mode: boot or resume? That difference could be coded in the C part of the kernel leaving a single asm entry point both for bootstrap and wakeup code. Am I making any sense? =D From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 4 10:44:19 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E8D916A407; Wed, 4 Oct 2006 10:44:19 +0000 (UTC) (envelope-from anders@FreeBSD.org) Received: from fupp.net (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67BDE43D46; Wed, 4 Oct 2006 10:44:18 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from localhost (totem.fix.no [80.91.36.20]) by fupp.net (Postfix) with ESMTP id B14A08D98A7; Wed, 4 Oct 2006 12:44:16 +0200 (CEST) Received: from fupp.net ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id 74490-01-3; Wed, 4 Oct 2006 12:44:16 +0200 (CEST) Received: by fupp.net (Postfix, from userid 1000) id 14FFE8D9897; Wed, 4 Oct 2006 12:44:16 +0200 (CEST) Date: Wed, 4 Oct 2006 12:44:16 +0200 From: Anders Nordby To: John Baldwin Message-ID: <20061004104415.GB23653@fupp.net> References: <200601052220.k05MK78w044322@freefall.freebsd.org> <200601060753.18180.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200601060753.18180.jhb@freebsd.org> X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: freebsd-acpi@freebsd.org, freebsd-smp@freebsd.org Subject: Re: Compaq DL 360 SMP problem (was: i386/89545: Compaq DL 360 ACPI boot problem) 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, 04 Oct 2006 10:44:19 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, And old mail here, but I still have this problem getting SMP to work on the machine. On Fri, Jan 06, 2006 at 07:53:17AM -0500, John Baldwin wrote: >> How can I get SMP running? This worked in 5.x and 4.x, I believe. > 2) Re: SMP, just to make sure, do you have 'device apic' and 'options SMP' in > your kernel? Also, can you provide the output of 'acpidump -t' so I can see > what your APIC table (MADT) looks like. Also, does the kernel find SMP if > you disable ACPI? Yes, apic is enabled in the kernel that I run. ACPI is loaded as a kernel module. If I disable ACPI, FreeBSD also finds only one processor. I still use the custom dsdt as modified after getting instructions by you in this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=89545. The modifications are: --- vm.asl Sat Jan 7 12:06:14 2006 +++ vm-fixed.asl Sat Jan 7 12:08:04 2006 @@ -5,13 +5,13 @@ /* RSDT: Length=52, Revision=1, Checksum=69, OEMID=COMPAQ, OEM Table ID=MICRO, OEM Revision=0x2, - Creator ID=Ò, Creator Revision=0x162e + Creator ID=ASL Creator Revision=0x162e Entries={ 0x67ffc040, 0x67ffc100, 0x67fff800, 0x67ffc180 } */ /* FACP: Length=116, Revision=1, Checksum=110, OEMID=COMPAQ, OEM Table ID=MICRO, OEM Revision=0x2, - Creator ID=Ò, Creator Revision=0x162e + Creator ID=ASL Creator Revision=0x162e FACS=0x67ffc0c0, DSDT=0x67ffc200 INT_MODEL=APIC Preferred_PM_Profile=Unspecified (0) @@ -84,7 +84,7 @@ /* SPCR: Length=80, Revision=1, Checksum=14, OEMID=COMPAQ, OEM Table ID=SPCR_ROM, OEM Revision=0x1, - Creator ID=Ò, Creator Revision=0x162e + Creator ID=ASL Creator Revision=0x162e */ /* * Intel ACPI Component Architecture @@ -1573,7 +1573,7 @@ Else { Store ("PCI0._PRT in PIC mode", Debug) - Return (Package (0x08) + Return (Package (0x07) { Package (0x04) { @@ -1588,14 +1588,6 @@ 0x0001FFFF, 0x01, ITR2, - 0x00 - }, - - Package (0x04) - { - 0x0004FFFF, - 0x00, - FAKE, 0x00 }, I'm running 6.1 on the system now, but still FreeBSD sees only one CPU. When booting the system it lists two: Processor 1 initialized at 800/133 MHz with 256 Kbyte Cache Processor 2 initialized at 800/133 MHz with 256 Kbyte Cache If I try to run with acpi but without the modified dsdt, I get these pci/cpu/apic/acpi messages on boot: CPU: Intel Pentium III (797.48-MHz 686-class CPU) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x240-0x243 on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci_link0: apparently invalid index 0 pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib2: on acpi0 pci_link4: BIOS IRQ 7 for 3.4.INTA is invalid pci_link2: BIOS IRQ 3 for 3.6.INTA is invalid pci3: on pcib2 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6ffffff,0xc6e00000-0xc6efffff irq 10 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dfffff,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc6bfffff irq 9 at device 6.0 on pci3 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 With the custom dsdt, I get: CPU: Intel Pentium III (797.48-MHz 686-class CPU) ACPI-0377: *** Info: Table [SSDT] replaced by host OS ACPI: overriding DSDT/SSDT with custom table ACPI-0377: *** Info: Table [DSDT] replaced by host OS acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x240-0x243 on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc 5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib2: on acpi0 pci_link4: BIOS IRQ 7 for 3.4.INTA is invalid pci_link2: BIOS IRQ 3 for 3.6.INTA is invalid pci3: on pcib2 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6fffff f,0xc6e00000-0xc6efffff irq 10 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dffff f,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc 6bfffff irq 9 at device 6.0 on pci3 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 If I run without ACPI, I get: CPU: Intel Pentium III (797.48-MHz 686-class CPU) cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc 5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib3: pcibus 3 on motherboard pci3: on pcib3 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6fffff f,0xc6e00000-0xc6efffff irq 7 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dffff f,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc 6bfffff irq 3 at device 6.0 on pci3 In any case, I only get one CPU. How to fix? Acpidump attached. Bye, -- Anders. --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="acpidump.txt" Content-Transfer-Encoding: quoted-printable /* RSD PTR: OEM=3DCOMPAQ, ACPI_Rev=3D1.0x (0) RSDT=3D0x67ffc000, cksum=3D250 */ /* RSDT: Length=3D52, Revision=3D1, Checksum=3D69, OEMID=3DCOMPAQ, OEM Table ID=3DMICRO, OEM Revision=3D0x2, Creator ID=3D=D2=04, Creator Revision=3D0x162e Entries=3D{ 0x67ffc040, 0x67ffc100, 0x67fff800, 0x67ffc180 } */ /* FACP: Length=3D116, Revision=3D1, Checksum=3D110, OEMID=3DCOMPAQ, OEM Table ID=3DMICRO, OEM Revision=3D0x2, Creator ID=3D=D2=04, Creator Revision=3D0x162e FACS=3D0x67ffc0c0, DSDT=3D0x67ffc200 INT_MODEL=3DAPIC Preferred_PM_Profile=3DUnspecified (0) SCI_INT=3D9 SMI_CMD=3D0x230, ACPI_ENABLE=3D0x1, ACPI_DISABLE=3D0x0, S4BIOS_REQ=3D0x0 PSTATE_CNT=3D0x0 PM1a_EVT_BLK=3D0x220-0x223 PM1a_CNT_BLK=3D0x230-0x231 PM_TMR_BLK=3D0x240-0x243 P_LVL2_LAT=3D65535 us, P_LVL3_LAT=3D65535 us FLUSH_SIZE=3D0, FLUSH_STRIDE=3D0 DUTY_OFFSET=3D0, DUTY_WIDTH=3D0 DAY_ALRM=3D0, MON_ALRM=3D0, CENTURY=3D0 IAPC_BOOT_ARCH=3D Flags=3D{WBINVD,PROC_C1,SLP_BUTTON,FIX_RTC} */ /* FACS: Length=3D64, HwSig=3D0x0000abcd, Firm_Wake_Vec=3D0x00000000 Global_Lock=3D Flags=3D Version=3D0 */ /* DSDT: Length=3D8075, Revision=3D1, Checksum=3D89, OEMID=3DCOMPAQ, OEM Table ID=3DDSDT, OEM Revision=3D0x1, Creator ID=3DMSFT, Creator Revision=3D0x100000b */ /* APIC: Length=3D94, Revision=3D1, Checksum=3D76, OEMID=3DCOMPAQ, OEM Table ID=3D00000083, OEM Revision=3D0x2, Creator ID=3D, Creator Revision=3D0x0 Local APIC ADDR=3D0xfee00000 Flags=3D{PC-AT} Type=3DLocal APIC ACPI CPU=3D0 Flags=3D{ENABLED} APIC ID=3D0 Type=3DLocal APIC ACPI CPU=3D1 Flags=3D{DISABLED} APIC ID=3D1 Type=3DLocal APIC ACPI CPU=3D2 Flags=3D{DISABLED} APIC ID=3D2 Type=3DLocal APIC ACPI CPU=3D3 Flags=3D{ENABLED} APIC ID=3D3 Type=3DIO APIC APIC ID=3D8 INT BASE=3D0 ADDR=3D0x00000000fec00000 Type=3DLocal NMI ACPI CPU=3DALL LINT Pin=3D1 Flags=3D{Polarity=3Dconforming, Trigger=3Dconforming} */ /* SSDT: Length=3D546, Revision=3D1, Checksum=3D240, OEMID=3DCOMPAQ, OEM Table ID=3DSSDT, OEM Revision=3D0x1, Creator ID=3DMSFT, Creator Revision=3D0x100000b */ /* SPCR: Length=3D80, Revision=3D1, Checksum=3D14, OEMID=3DCOMPAQ, OEM Table ID=3DSPCR_ROM, OEM Revision=3D0x1, Creator ID=3D=D2=04, Creator Revision=3D0x162e */ --TB36FDmn/VVEgNH/-- From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 4 11:36:33 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 620AD16A403; Wed, 4 Oct 2006 11:36:33 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from altrade.nijmegen.internl.net (altrade.nijmegen.internl.net [217.149.192.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C009E43D49; Wed, 4 Oct 2006 11:36:32 +0000 (GMT) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org by altrade.nijmegen.internl.net via 113-9.bbned.dsl.internl.net [82.215.9.113] with ESMTP id k94BaUNU005518 (8.13.2/2.04); Wed, 4 Oct 2006 13:36:31 +0200 (MET DST) Received: from localhost (localhost.homebrew.bsd4all.org [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id 7D12E5C92; Wed, 4 Oct 2006 13:36:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by localhost (fwgw.homebrew.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVz+6WZZ0Chm; Wed, 4 Oct 2006 13:36:15 +0200 (CEST) Received: from beast (beast [192.168.1.138]) by mail.bsd4all.org (Postfix) with ESMTP id 17BF65C1C; Wed, 4 Oct 2006 13:36:15 +0200 (CEST) From: "Peter Blok" To: "'Anders Nordby'" , "'John Baldwin'" Date: Wed, 4 Oct 2006 13:34:24 +0200 Message-ID: <000901c6e7a9$0b32b680$8a01a8c0@beast> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20061004104415.GB23653@fupp.net> Thread-Index: AcbnomkPZXfG9QyWQpKt3Ju5i8sbbAABmxEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: freebsd-acpi@freebsd.org, freebsd-smp@freebsd.org Subject: RE: Compaq DL 360 SMP problem (was: i386/89545: Compaq DL 360 ACPIboot problem) 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, 04 Oct 2006 11:36:33 -0000 According to the acpidump you have CPU=3D0 and CPU=3D3. CPU 1 and CPU 2 = are marked disabled. Are you able to move the CPU hardware wise? Peter -----Original Message----- From: owner-freebsd-smp@freebsd.org = [mailto:owner-freebsd-smp@freebsd.org] On Behalf Of Anders Nordby Sent: Wednesday, October 04, 2006 12:44 PM To: John Baldwin Cc: freebsd-acpi@freebsd.org; freebsd-smp@freebsd.org Subject: Re: Compaq DL 360 SMP problem (was: i386/89545: Compaq DL 360 ACPIboot problem) Hi, And old mail here, but I still have this problem getting SMP to work on the machine. On Fri, Jan 06, 2006 at 07:53:17AM -0500, John Baldwin wrote: >> How can I get SMP running? This worked in 5.x and 4.x, I believe. > 2) Re: SMP, just to make sure, do you have 'device apic' and 'options = SMP' in=20 > your kernel? Also, can you provide the output of 'acpidump -t' so I = can see=20 > what your APIC table (MADT) looks like. Also, does the kernel find = SMP if > you disable ACPI? Yes, apic is enabled in the kernel that I run. ACPI is loaded as a kernel module. If I disable ACPI, FreeBSD also finds only one processor. I still use the custom dsdt as modified after getting instructions by you in this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=3D89545. The modifications are: --- vm.asl Sat Jan 7 12:06:14 2006 +++ vm-fixed.asl Sat Jan 7 12:08:04 2006 @@ -5,13 +5,13 @@ /* RSDT: Length=3D52, Revision=3D1, Checksum=3D69, OEMID=3DCOMPAQ, OEM Table ID=3DMICRO, OEM Revision=3D0x2, - Creator ID=3D=D2, Creator Revision=3D0x162e + Creator ID=3DASL Creator Revision=3D0x162e Entries=3D{ 0x67ffc040, 0x67ffc100, 0x67fff800, 0x67ffc180 } */ /* FACP: Length=3D116, Revision=3D1, Checksum=3D110, OEMID=3DCOMPAQ, OEM Table ID=3DMICRO, OEM Revision=3D0x2, - Creator ID=3D=D2, Creator Revision=3D0x162e + Creator ID=3DASL Creator Revision=3D0x162e FACS=3D0x67ffc0c0, DSDT=3D0x67ffc200 INT_MODEL=3DAPIC Preferred_PM_Profile=3DUnspecified (0) @@ -84,7 +84,7 @@ /* SPCR: Length=3D80, Revision=3D1, Checksum=3D14, OEMID=3DCOMPAQ, OEM Table ID=3DSPCR_ROM, OEM Revision=3D0x1, - Creator ID=3D=D2, Creator Revision=3D0x162e + Creator ID=3DASL Creator Revision=3D0x162e */ /* * Intel ACPI Component Architecture @@ -1573,7 +1573,7 @@ Else { Store ("PCI0._PRT in PIC mode", Debug) - Return (Package (0x08) + Return (Package (0x07) { Package (0x04) { @@ -1588,14 +1588,6 @@ 0x0001FFFF,=20 0x01,=20 ITR2,=20 - 0x00 - },=20 - - Package (0x04) - { - 0x0004FFFF,=20 - 0x00,=20 - FAKE,=20 0x00 },=20 I'm running 6.1 on the system now, but still FreeBSD sees only one CPU. When booting the system it lists two: Processor 1 initialized at 800/133 MHz with 256 Kbyte Cache Processor 2 initialized at 800/133 MHz with 256 Kbyte Cache If I try to run with acpi but without the modified dsdt, I get these pci/cpu/apic/acpi messages on boot: CPU: Intel Pentium III (797.48-MHz 686-class CPU) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x240-0x243 on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci_link0: apparently invalid index 0 pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib2: on acpi0 pci_link4: BIOS IRQ 7 for 3.4.INTA is invalid pci_link2: BIOS IRQ 3 for 3.6.INTA is invalid pci3: on pcib2 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6ffffff,0xc6e00000-0xc6efffff irq 10 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dfffff,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc6bfffff irq 9 at device 6.0 on pci3 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 With the custom dsdt, I get: CPU: Intel Pentium III (797.48-MHz 686-class CPU) ACPI-0377: *** Info: Table [SSDT] replaced by host OS ACPI: overriding DSDT/SSDT with custom table ACPI-0377: *** Info: Table [DSDT] replaced by host OS acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x240-0x243 on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc 5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib2: on acpi0 pci_link4: BIOS IRQ 7 for 3.4.INTA is invalid pci_link2: BIOS IRQ 3 for 3.6.INTA is invalid pci3: on pcib2 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6fffff f,0xc6e00000-0xc6efffff irq 10 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dffff f,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc 6bfffff irq 9 at device 6.0 on pci3 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 If I run without ACPI, I get: CPU: Intel Pentium III (797.48-MHz 686-class CPU) cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 ida0: port 0x2000-0x20ff mem 0xc5000000-0xc 5ffffff,0xc4000000-0xc4ffffff irq 5 at device 1.0 on pci0 pci0: at device 3.0 (no driver attached) pci0: at device 4.0 (no driver attached) pcib1: at device 5.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 5.1 (no driver attached) isab0: at device 15.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x2800-0x280f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcib3: pcibus 3 on motherboard pci3: on pcib3 fxp0: port 0x4000-0x403f mem 0xc6fff000-0xc6fffff f,0xc6e00000-0xc6efffff irq 7 at device 4.0 on pci3 fxp1: port 0x4040-0x407f mem 0xc6dff000-0xc6dffff f,0xc6c00000-0xc6cfffff irq 10 at device 5.0 on pci3 ida1: port 0x4400-0x44ff mem 0xc6bff000-0xc 6bfffff irq 3 at device 6.0 on pci3 In any case, I only get one CPU. How to fix? Acpidump attached. Bye, --=20 Anders. From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 4 13:22:51 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2CE916A75E; Wed, 4 Oct 2006 13:22:51 +0000 (UTC) (envelope-from BryonGoinsbu@arcor-ip.net) Received: from arcor-ip.net (dslb-088-073-196-004.pools.arcor-ip.net [88.73.196.4]) by mx1.FreeBSD.org (Postfix) with SMTP id A9FB743D5C; Wed, 4 Oct 2006 13:22:50 +0000 (GMT) (envelope-from BryonGoinsbu@arcor-ip.net) Message-Id: <924125985.10588268@arcor-ip.net> From: "Loyd Engle" To: , Date: Wed, 04 Oct 2006 15:22:50 +0100 MIME-Version: 1.0 Cc: freebsd-admin@freebsd.org Subject: biminii 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, 04 Oct 2006 13:22:51 -0000 Energy Prices are near all time low, This is the best time to lock in a quality energy stock Introducing : WBRS Exchange Pinksheets Price: 0.05 3 Day Estimated : .50 ( +1000%) WILD BRUSH MAKES A MOVE! Wild Brush Acquires Additional Powder River Oil & Gas Lease. Who is Wild Brush? Wild Brush Energy is a diversified energy company whose primary goal is to identify and develop Oil & Coalbed Methane sites within the State of Wyoming. In addition, Wild Brush Energy continues to evaluate clean air alternative energy producing technologies such as Wind Power. Wild Brush trades in the U.S. under the symbol "WBRS." ADD THIS ENERGY STOCK TO YOUR LIST AND WATCH IT TRADE CLOSELY ON WEDNESDAY OCTOBER 4! Get In NOW !!! Shake like a leaf. Water doesn't run uphill. Your all washed up. Tools of the trade. Red as a beet. What on earth? Your ass is grass. Stuck in a rut. The season of goodwill. Still water runs dirty and deep. Walking on thin ice. Shall I compare thee to a summer's day. Scraping the bottom of the barrel. From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 4 18:56:13 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FCE916A412; Wed, 4 Oct 2006 18:56:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E82F543D68; Wed, 4 Oct 2006 18:56:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k94Itg8o036809; Wed, 4 Oct 2006 14:55:45 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andrea Bittau Date: Wed, 4 Oct 2006 13:41:33 -0400 User-Agent: KMail/1.9.1 References: <20060921000628.GA1832@shorty.sorbonet.org> <4522D023.9090501@root.org> <20061003213356.GA6149@shorty.sorbonet.org> In-Reply-To: <20061003213356.GA6149@shorty.sorbonet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610041341.34231.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 04 Oct 2006 14:55:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1997/Wed Oct 4 11:20:43 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] 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, 04 Oct 2006 18:56:13 -0000 On Tuesday 03 October 2006 17:33, Andrea Bittau wrote: > On Tue, Oct 03, 2006 at 02:03:31PM -0700, Nate Lawson wrote: > > I agree. The standard switch to protected mode, paging, etc. needs to > > be performed and then resume from the saved register context. > > I guess my point was that there are two pieces of code that do that: > 1) mpboot.s bootMP() used by system bootstrap and what my current patch uses. I > think this is what you guys are suggesting to use, and I'm doing it anyway in > my patch, but I just want to be the devil's advocate =D. > > 2) acpi_wakecode.S wakeup_16() used by the BSP to wake itself up. This is what > I was suggesting should be generalized and used by the other cores too. The > difference of this code as opposed to #1 is that #2 can "cheat". That is, we > can create the code for #2 on the fly and do stuff like mov old_eax,eax etc > and don't have to be smart about figuring out where the CPU should land and > how it should initialize itself [as in the case of #1]. > > I'm just wondering whether we should do something about the assembly "code > duplication" in #1 and #2. I understand they serve a different purpose, but > arguably, they do the same thing: real-mode -> jump in kernel. What is > different is what happens once in kernel mode: boot or resume? That difference > could be coded in the C part of the kernel leaving a single asm entry point both > for bootstrap and wakeup code. Am I making any sense? =D 1) is already tailored to work with starting up an extra AP based on the STARTUP IPI, so I think we should reuse it for starting up the cores. I need to think about it more though. First we need to get APIC with UP working though. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 5 05:44:46 2006 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCBBA16A407 for ; Thu, 5 Oct 2006 05:44:46 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7818943D60 for ; Thu, 5 Oct 2006 05:44:40 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.46.150] Received: from [10.0.5.50] (ppp-71-139-46-150.dsl.snfc21.pacbell.net [71.139.46.150]) by ylpvm12.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k955gf6m030613; Thu, 5 Oct 2006 01:42:42 -0400 Message-ID: <45249B8F.2060407@root.org> Date: Wed, 04 Oct 2006 22:43:43 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kevin Oberman References: <20060823043830.6E09245055@ptavv.es.net> In-Reply-To: <20060823043830.6E09245055@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: Odd power management on ThinkPad T43 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2006 05:44:46 -0000 Kevin Oberman wrote: > I'm running current on an IBM ThinkPad T43 and I'm not sure I have a problem, > but something odd seems to be going on. > > I have a 2.0 GHz Pentium-M which I believe is 760. I believe it's one IBM has > not released information on the EST specs. > > If I do NOT have cpufreq loaded, I see: > dev.cpu.0.freq_levels: 2000/27000 1750/23625 1600/22600 1400/19775 1333/19666 > 1166/17207 1066/16733 932/14641 800/13800 700/12075 600/10350 500/8625 > 400/6900 300/5175 200/3450 100/1725 > > If I load cpufreq I see: > dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 > 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 > > With cpufreq I report perf0, est0 and p4tcc0 in dmesg. Without loading cpufreq > I still see acpi_perf0 and acpi_throttle0. > > This would lead me to believe that without cpufreq I am only seeing > throttling, but I see my clock speed decrease (x86info) which I did not expect > to see with pure throttling. > > Am I better off when on battery to use cpufreq or not? Is there something to > tweak to get full 2GHz performance with EST? This sounds like a bad table match for est0. Perhaps it's detecting your CPU as a 1.5Ghz one when it's actually 2Ghz. An easy way to tell is to load cpufreq but disable just est with: hint.est.0.disabled="1" You should get acpi_perf and p4tcc, and the frequencies will be correct for your system. acpi_perf is often more user-friendly anyway since it reports the power consumed at each level instead of just "-1". It's also possible you were booting on battery and had lower levels available. Easy way to tell is report output of sysctl -a | grep cpu -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 7 09:49:05 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FAEC16A523 for ; Sat, 7 Oct 2006 09:49:05 +0000 (UTC) (envelope-from garrigue@math.nagoya-u.ac.jp) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3F8143D45 for ; Sat, 7 Oct 2006 09:49:03 +0000 (GMT) (envelope-from garrigue@math.nagoya-u.ac.jp) Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id k979n0aU026441; Sat, 7 Oct 2006 18:49:01 +0900 (JST) Date: Sat, 07 Oct 2006 18:49:02 +0900 (JST) Message-Id: <20061007.184902.07645150.garrigue@math.nagoya-u.ac.jp> To: freebsd-acpi@freebsd.org From: Jacques Garrigue X-Mailer: Mew version 5.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Sony Vaio VGN-TX92S X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2006 09:49:05 -0000 Hi, I've just installed FreeBSD 6.2-BETA2 on a Vaio VGN-TX92S, which is a Centrino laptop with a Core Solo U1400, ICH7 chipset. After a bit of fiddling, I can use most features: * Xorg in 1368x768 mode (nothing to do) * integrated ethernet (just had to add the board ID to if_fxp.c) * wireless (download and compile wpi-freebsd.tgz) * HDA audio (download and compile hdac driver, as snd_hda didn't compile) * USB, pccard, bluetooth (nothing to do) So I should be happy, but I have two problems. The most usual one is that it doesn't resume after suspend: acpiconf -s3 does go to sleep, but it hangs on resume. I don't know if there is an easy solution, but I would take any hint. The more unusual one is that it gets rather hot. After a few minutes, the fan starts, and never stops. The temperature reading quickly goes to 58C, and stays there, but may go to 65C under load (the machine feels actually hot.) I even got some hang-ups that look like overheat. Under windows it gets hot at times, but not that easily. Note that cpufreq seems to work: when idle, the frequency goes down to 100MHz. In case it helps, here are the results of pciconf -lv, and dmesg after a verbose boot. Cheers, Jacques Garrigue % pciconf -lv hostb0@pci0:0:0: class=0x060000 card=0x8207104d chip=0x27a08086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI none0@pci0:2:0: class=0x030000 card=0x8207104d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA none1@pci0:2:1: class=0x038000 card=0x8207104d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display pcm0@pci0:27:0: class=0x040300 card=0x8207104d chip=0x27d88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class = multimedia pcib1@pci0:28:0: class=0x060400 card=0x00000040 chip=0x27d08086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0x8207104d chip=0x27c88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x8207104d chip=0x27c98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x8207104d chip=0x27ca8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0x8207104d chip=0x27cb8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x8207104d chip=0x27cc8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib2@pci0:30:0: class=0x060401 card=0x00000050 chip=0x24488086 rev=0xe2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x8207104d chip=0x27b98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x8207104d chip=0x27df8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA none2@pci0:31:3: class=0x0c0500 card=0x8207104d chip=0x27da8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus wpi0@pci2:0:0: class=0x028000 card=0x10538086 chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network cbb0@pci6:4:0: class=0x060700 card=0x8207104d chip=0x8039104c rev=0x00 hdr=0x02 vendor = 'Texas Instruments (TI)' class = bridge subclass = PCI-CardBus fwohci0@pci6:4:1: class=0x0c0010 card=0x8207104d chip=0x803a104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' class = serial bus subclass = FireWire none3@pci6:4:2: class=0x018000 card=0x8207104d chip=0x803b104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' class = mass storage fxp0@pci6:8:0: class=0x020000 card=0x8207104d chip=0x10938086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet dmesg: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-BETA2 #0: Thu Oct 5 09:05:35 JST 2006 root@:/usr/src/sys/i386/compile/MARIE Preloaded elf kernel "/boot/kernel/kernel" at 0xc083c000. Preloaded elf module "/boot/kernel/umodem.ko" at 0xc083c228. Preloaded elf module "/boot/kernel/ucom.ko" at 0xc083c2d4. Preloaded elf module "/boot/kernel/acpi_video.ko" at 0xc083c380. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc083c430. Preloaded elf module "/boot/kernel/acpi_sony.ko" at 0xc083c4dc. Preloaded elf module "/boot/kernel/firmware.ko" at 0xc083c58c. Preloaded elf module "/boot/kernel/hdac.ko" at 0xc083c63c. Preloaded elf module "/boot/kernel/sound.ko" at 0xc083c6e8. Preloaded elf module "/boot/kernel/cpufreq.ko" at 0xc083c794. Preloaded elf module "/boot/kernel/ng_ubt.ko" at 0xc083c840. Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc083c8ec. MP Configuration Table version 1.4 found at 0xc009fd71 Table 'FACP' at 0x1f692dec Table 'APIC' at 0x1f692e70 MADT: Found table at 0x1f692e70 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 1 ACPI ID 1: disabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193190 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1197012303 Hz CPU: Genuine Intel(R) CPU U1400 @ 1.20GHz (1197.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 Features=0xafe9fbff Features2=0xc1a9,> AMD Features=0x100000 real memory = 526909440 (502 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001ed66fff, 504635392 bytes (123202 pages) avail memory = 506208256 (482 MB) bios32: Found BIOS32 Service Directory header at 0xc00f63f0 bios32: Entry = 0xfd5b0 (c00fd5b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd5b0+0x273 pnpbios: Found PnP BIOS data at 0xc00f6450 pnpbios: Entry = f0000:8605 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 io: random: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f920 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=27a08086) pcibios: BIOS version 2.10 Found $PIR table, 20 entries at 0xc00fde80 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 0 A 0x60 10 embedded 0 0 B 0x61 10 embedded 0 0 C 0x62 10 embedded 0 0 D 0x63 10 embedded 0 7 A 0x60 10 embedded 0 1 A 0x60 10 embedded 0 1 B 0x61 10 slot 6 1 0 A 0x60 10 slot 6 1 0 B 0x61 10 slot 6 1 0 C 0x62 10 slot 6 1 0 D 0x63 10 embedded 0 2 A 0x60 10 embedded 0 2 B 0x61 10 embedded 0 27 A 0x63 10 embedded 0 28 A 0x60 10 embedded 0 28 B 0x61 10 embedded 0 28 C 0x62 10 embedded 0 28 D 0x63 10 slot 7 2 0 A 0x60 10 slot 7 2 0 B 0x61 10 slot 7 2 0 C 0x62 10 slot 7 2 0 D 0x63 10 slot 8 255 0 A 0x61 10 slot 8 255 0 B 0x62 10 slot 8 255 0 C 0x63 10 slot 8 255 0 D 0x60 10 slot 9 255 0 A 0x62 10 slot 9 255 0 B 0x63 10 slot 9 255 0 C 0x60 10 slot 9 255 0 D 0x61 10 slot 10 255 0 A 0x63 10 slot 10 255 0 B 0x60 10 slot 10 255 0 C 0x61 10 slot 10 255 0 D 0x62 10 slot 11 255 0 A 0x60 10 slot 11 255 0 B 0x61 10 slot 11 255 0 C 0x62 10 slot 11 255 0 D 0x63 10 slot 12 255 0 A 0x61 10 slot 12 255 0 B 0x62 10 slot 12 255 0 C 0x63 10 slot 12 255 0 D 0x60 10 embedded 0 29 A 0x61 10 embedded 0 29 B 0x63 10 embedded 0 29 C 0x69 10 embedded 0 29 D 0x6b 10 embedded 0 30 A 0x6a 10 embedded 0 30 B 0x68 10 slot 1 6 4 A 0x68 10 slot 1 6 4 B 0x69 10 slot 1 6 4 C 0x6a 10 slot 1 6 4 D 0x6b 10 embedded 6 5 A 0x62 10 embedded 6 5 C 0x68 10 embedded 6 5 D 0x6b 10 embedded 6 8 A 0x68 10 slot 2 6 11 A 0x61 10 slot 2 6 11 B 0x62 10 embedded 0 31 B 0x6a 10 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 6 dev 4 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: wakeup code va 0xcd37a000 pa 0x9e000 acpi_bus_number: root bus has no _BBN, assuming 0 acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 10 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 10 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x27a0, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27a2, revid=0x03 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type 1, range 32, base d4100000, size 19, enabled map[14]: type 4, range 32, base 00001800, size 3, enabled map[18]: type 3, range 32, base c0000000, size 28, enabled map[1c]: type 1, range 32, base d4200000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27a6, revid=0x03 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d4180000, size 19, enabled found-> vendor=0x8086, dev=0x27d8, revid=0x02 bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 64, base d4240000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27d0, revid=0x02 bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27c9, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type 4, range 32, base 00001860, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x27cb, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27cc, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base d4444000, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xe2 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b9, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=255 map[20]: type 4, range 32, base 00001810, size 4, enabled found-> vendor=0x8086, dev=0x27da, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 000018a0, size 5, enabled pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pcm0: mem 0xd4240000-0xd4243fff irq 19 at device 27.0 on pci0 init 0xc32ee280 pcm0: sndbuf_setmap 1cc000, 1000; 0xc32f8000 -> 1cc000 pcm0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd4240000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 pcm0: [MPSAFE] pcm0: Output Streams: 4, Input Streams: 4, Bidirectional Streams: 0 pcm0: CORB Size: 256, RIRB Size: 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: secondary bus 2 pcib1: subordinate bus 5 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xd2000000-0xd3ffffff pcib1: prefetched decode 0xd0000000-0xd1ffffff pci2: on pcib1 pci2: physical bus=2 found-> vendor=0x8086, dev=0x4222, revid=0x02 bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base d2000000, size 12, enabled pcib1: (null) requested memory range 0xd2000000-0xd2000fff: good pcib1: matched entry for 2.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 pci2: at device 0.0 (no driver attached) uhci0: port 0x1820-0x183f irq 17 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 50 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 21 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 51 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 17 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd4444000-0xd44443ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd4444000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 6 pcib2: subordinate bus 7 pcib2: I/O decode 0x3000-0x3fff pcib2: memory decode 0xd4000000-0xd40fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci6: on pcib2 pci6: physical bus=6 found-> vendor=0x104c, dev=0x8039, revid=0x00 bus=6, slot=4, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, enabled found-> vendor=0x104c, dev=0x803a, revid=0x00 bus=6, slot=4, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x04 (1000 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d4006000, size 11, enabled pcib2: (null) requested memory range 0xd4006000-0xd40067ff: good map[14]: type 1, range 32, base d4000000, size 14, enabled pcib2: (null) requested memory range 0xd4000000-0xd4003fff: good pcib2: matched entry for 6.4.INTB pcib2: slot 4 INTB hardwired to IRQ 21 found-> vendor=0x104c, dev=0x803b, revid=0x00 bus=6, slot=4, func=2 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x39 (1710 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d4004000, size 12, enabled pcib2: (null) requested memory range 0xd4004000-0xd4004fff: good pcib2: matched entry for 6.4.INTC pcib2: slot 4 INTC hardwired to IRQ 22 found-> vendor=0x8086, dev=0x1093, revid=0x02 bus=6, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d4005000, size 12, enabled pcib2: (null) requested memory range 0xd4005000-0xd4005fff: good map[14]: type 4, range 32, base 00003000, size 6, enabled pcib2: (null) requested I/O range 0x3000-0x303f: in range pcib2: matched entry for 6.8.INTA pcib2: slot 8 INTA hardwired to IRQ 20 cbb0: at device 4.0 on pci6 pcib2: cbb0 requested memory range 0xd4000000-0xd40fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xd4007000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 6.4.INTA pcib2: slot 4 INTA hardwired to IRQ 20 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 53 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x8039104c 0x02100007 0x06070000 0x00824010 0x10: 0xd4007000 0x020000a0 0x40070706 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400114 0x40: 0x8207104d 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x08449060 0x84d30019 0x000f0000 0x01a21b22 0x90: 0x606400c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x08000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x39022113 0x10019727 0x00000000 0x00000000 fwohci0: vendor=104c, dev=803a fwohci0: vendor=104c, dev=803a fwohci0: <1394 Open Host Controller Interface> mem 0xd4006000-0xd40067ff,0xd4000000-0xd4003fff irq 21 at device 4.1 on pci6 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xd4006000 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:02:27:29:c9 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci6: at device 4.2 (no driver attached) fxp0: port 0x3000-0x303f mem 0xd4005000-0xd4005fff irq 20 at device 8.0 on pci6 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd4005000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1093 104d 8207 0002 fxp0: Dynamic Standby mode is enabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:13:a9:40:b8:92 fxp0: [MPSAFE] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1810 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 55 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_sony0: on acpi0 acpi_sony0: PID 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 57 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 battery0: on acpi0 acpi_acad0: on acpi0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0: not probed (disabled) sio1: not probed (disabled) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ubt0: ALPS UGX, rev 2.00/19.15, addr 2 ubt0: ALPS UGX, rev 2.00/19.15, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 ugen0: vendor 0x054c product 0x01bb, rev 2.00/1.28, addr 3 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 66500344 hz Timecounter "TSC" frequency 1197012303 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire battery0: battery initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ICH7 chip ad0: setting UDMA100 on ICH7 chip ad0: 57231MB at ata0-master UDMA100 ad0: 117210240 sectors [116280C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 acpi_acad0: acline initialization start battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as slave acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: Vendor info: 10ec0262 10ec 262 1 0 1 pcm0: Vendor info: 14f12bfa 14f1 2bfa 0 0 2 pcm0: