From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 07:56:46 2004 Return-Path: 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 781D416A4CE for ; Mon, 31 May 2004 07:56:46 -0700 (PDT) Received: from zeus.ubbcluj.ro (NS2.UBBCluj.Ro [193.231.20.1]) by mx1.FreeBSD.org (Postfix) with SMTP id A124F43D1F for ; Mon, 31 May 2004 07:56:45 -0700 (PDT) (envelope-from dan@zeus.ubbcluj.ro) Received: (qmail 75011 invoked by uid 1002); 31 May 2004 14:56:41 -0000 Date: Mon, 31 May 2004 17:56:41 +0300 From: Dan Cojocar To: freebsd-acpi@freebsd.org Message-ID: <20040531145641.GA74327@Zeus.UBBCluj.Ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: asl question X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 14:56:46 -0000 Hello, What should i do, to fix an error like this: my.asl 884: Field (U1D3, WordAcc, NoLock, Preserve) Error 1047 - ^ Access width is greater than region size Here is my full asl: http://cs.ubbcluj.ro/~dan/my.asl Thanks, Dan From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 11:02:01 2004 Return-Path: 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 3B0DC16A4CF for ; Mon, 31 May 2004 11:02:01 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3558443D1D for ; Mon, 31 May 2004 11:02:01 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i4VI1glj022625 for ; Mon, 31 May 2004 11:01:42 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4VI1fF4022619 for freebsd-acpi@freebsd.org; Mon, 31 May 2004 11:01:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 May 2004 11:01:41 -0700 (PDT) Message-Id: <200405311801.i4VI1fF4022619@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 18:02:01 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/09/09] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2004/01/31] kern/62194 acpi kern/acpi: Unable to map IRQ on device cb 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/12/16] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/08/11] i386/55473 acpi Mouse broken on some AWARD BIOS with ACPI o [2004/03/17] misc/64365 acpi ACPI problems o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) 3 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 11:08:57 2004 Return-Path: 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 D8CCC16A4D6 for ; Mon, 31 May 2004 11:08:57 -0700 (PDT) Received: from fep2.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6869443D48 for ; Mon, 31 May 2004 11:08:57 -0700 (PDT) (envelope-from paul.murphy@cogeco.ca) Received: from earth.upton.net (d141-23-108.home.cgocable.net [24.141.23.108]) by fep2.cogeco.net (Postfix) with SMTP id 8B61C2066 for ; Mon, 31 May 2004 14:08:19 -0400 (EDT) Date: Mon, 31 May 2004 14:08:12 -0400 From: Paul Murphy To: freebsd-acpi@freebsd.org Message-Id: <20040531140812.321e8293@earth.upton.net> In-Reply-To: <20040531145641.GA74327@Zeus.UBBCluj.Ro> References: <20040531145641.GA74327@Zeus.UBBCluj.Ro> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) X-Face: -Q/~XHbe$z/a List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 18:08:58 -0000 --Signature=_Mon__31_May_2004_14_08_13_-0400_wAVN3AoS7wJL7.Hd Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Mon, 31 May 2004 17:56:41 +0300 Dan Cojocar wrote: > Hello, > > What should i do, to fix an error like this: > > my.asl 884: Field (U1D3, WordAcc, NoLock, > Preserve) Error 1047 - ^ Access width > is greater than region size > > Here is my full asl: http://cs.ubbcluj.ro/~dan/my.asl > Thanks, > Dan > Have a look here: http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt -- Cogeco ergo sum --Signature=_Mon__31_May_2004_14_08_13_-0400_wAVN3AoS7wJL7.Hd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAu3ST2Ev+mfbss0wRAj/IAJ9PqASHpOoh+tZoNfAAqfaeYSc3YQCfe8b4 9vb2N1ZHtGhOdFaU9VPh/Ps= =d+8c -----END PGP SIGNATURE----- --Signature=_Mon__31_May_2004_14_08_13_-0400_wAVN3AoS7wJL7.Hd-- From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 13:18:34 2004 Return-Path: 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 3CB9C16A4CE; Mon, 31 May 2004 13:18:34 -0700 (PDT) Received: from imap.univie.ac.at (mailbox-lmtp.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4979043D2D; Mon, 31 May 2004 13:18:33 -0700 (PDT) (envelope-from le@FreeBSD.org) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i4VKI2mf1292276; Mon, 31 May 2004 22:18:05 +0200 Date: Mon, 31 May 2004 22:18:05 +0200 (CEST) From: Lukas Ertl To: Nate Lawson In-Reply-To: <20040528003424.E96434@root.org> Message-ID: <20040531221718.F644@korben> References: <20040528003424.E96434@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx8 4247; Body=3 Fuz1=3 Fuz2=3 cc: acpi@FreeBSD.org cc: current@FreeBSD.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 20:18:34 -0000 On Fri, 28 May 2004, Nate Lawson wrote: > I've just finished a lot of work on acpi events (GPEs). These drive > things like the lid switch and device wake capabilities. If your system > works for suspend/resume, please make sure it still behaves correctly over > multiple suspend/resume cycles. Thanks, Nate. I didn't play around a lot with it, but normal suspend/resume/power off still works fine here. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 14:30:56 2004 Return-Path: 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 A357016A4CE; Mon, 31 May 2004 14:30:56 -0700 (PDT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B7EB43D1F; Mon, 31 May 2004 14:30:56 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 31 May 2004 14:30:45 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6E8BE5D0A; Mon, 31 May 2004 14:30:45 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Fri, 28 May 2004 00:38:32 PDT." <20040528003424.E96434@root.org> Date: Mon, 31 May 2004 14:30:45 -0700 From: "Kevin Oberman" Message-Id: <20040531213045.6E8BE5D0A@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 21:30:56 -0000 > Date: Fri, 28 May 2004 00:38:32 -0700 (PDT) > From: Nate Lawson > Sender: owner-freebsd-current@freebsd.org > > I've just finished a lot of work on acpi events (GPEs). These drive > things like the lid switch and device wake capabilities. If your system > works for suspend/resume, please make sure it still behaves correctly over > multiple suspend/resume cycles. If you're feeling adventurous, try the > new wake sysctls: > > sysctl dev | grep wake > > By setting them to 0 or 1, you can enable/disable a device waking the > system. Note that non-ACPI devices are still not properly hooked in here > so they won't work (i.e. sio or modems). But you can change the lid > independently of the sleep button, for example. > > Also, please be sure that your system still powers off correctly when > shutdown. I may have fixed some systems that didn't power off correctly > as well. Things are working pretty well on my trusty T30. System suspends and resumes fine (with the jhb acpi_video_dpms patch). Only sound fails to work properly after resume, but I've reported this in the past and I still suspect it's a PCI issue as opposed to ACPI. I did try the sysctl to disable wake on lid switch and it worked as expected. I had to back out jhb's machdep_intr.c 1.6 patch to get the system to complete a shutdown. With the patch in place, the shutdown simply freezes after shutting down everything and syncing disks. I still hope to get suspend/resume with working sound one day, but ACPI seems really, really close. I am no longer seeing the interrupt issues previously reported. I have now repeatedly paused the system and resumed it with no obvious ill effects. I have also suspended and resumed using Tobias Roth's profile tool and the crashes previously seen with ACPI there are gone. (Not that profile resumes cleanly yet, but Tobias is working on the problems.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 21:03:18 2004 Return-Path: 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 34EDC16A4CE for ; Mon, 31 May 2004 21:03:18 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 01B3B43D5A for ; Mon, 31 May 2004 21:03:18 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 23651 invoked by uid 1000); 1 Jun 2004 04:03:20 -0000 Date: Mon, 31 May 2004 21:03:19 -0700 (PDT) From: Nate Lawson To: Paul Murphy In-Reply-To: <20040531140812.321e8293@earth.upton.net> Message-ID: <20040531210236.X23630@root.org> References: <20040531145641.GA74327@Zeus.UBBCluj.Ro> <20040531140812.321e8293@earth.upton.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: asl question X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 04:03:18 -0000 On Mon, 31 May 2004, Paul Murphy wrote: > On Mon, 31 May 2004 17:56:41 +0300 > Dan Cojocar wrote: > > > Hello, > > > > What should i do, to fix an error like this: > > > > my.asl 884: Field (U1D3, WordAcc, NoLock, > > Preserve) Error 1047 - ^ Access width > > is greater than region size > > > > Here is my full asl: http://cs.ubbcluj.ro/~dan/my.asl > > Thanks, > > Dan > > Have a look here: > http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt I want to point out that this and other FreeBSD ACPI questions are answered in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -Nate From owner-freebsd-acpi@FreeBSD.ORG Mon May 31 21:06:46 2004 Return-Path: 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 A2F5816A4CF for ; Mon, 31 May 2004 21:06:46 -0700 (PDT) Received: from mail.corrupt.co.nz (222-152-28-228.jetstream.xtra.co.nz [222.152.28.228]) by mx1.FreeBSD.org (Postfix) with SMTP id 2AC2B43D3F for ; Mon, 31 May 2004 21:06:45 -0700 (PDT) (envelope-from drew@corrupt.co.nz) Received: (qmail 29670 invoked by uid 1011); 1 Jun 2004 04:06:46 -0000 Received: from drew@corrupt.co.nz by tweety.lan.corrupt.co.nz by uid 1009 with qmail-scanner-1.22 Clear:RC:0(192.100.53.164):SA:0(0.0/3.8):. Processed in 5.321627 secs); 01 Jun 2004 04:06:46 -0000 X-Spam-Status: No, hits=0.0 required=3.8 Received: from 192.100.53.164.dts.net.nz (HELO corrupt.co.nz) (drew@corrupt.co.nz@192.100.53.164) by mail.corrupt.co.nz with SMTP; 1 Jun 2004 04:06:40 -0000 Message-ID: <40BC00AD.6010106@corrupt.co.nz> Date: Tue, 01 Jun 2004 16:06:05 +1200 From: Drew Broadley User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040505 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20040531213045.6E8BE5D0A@ptavv.es.net> In-Reply-To: <20040531213045.6E8BE5D0A@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 04:06:46 -0000 Kevin Oberman wrote: >>Date: Fri, 28 May 2004 00:38:32 -0700 (PDT) >>From: Nate Lawson >>Sender: owner-freebsd-current@freebsd.org >> >>I've just finished a lot of work on acpi events (GPEs). These drive >>things like the lid switch and device wake capabilities. If your system >>works for suspend/resume, please make sure it still behaves correctly over >>multiple suspend/resume cycles. If you're feeling adventurous, try the >>new wake sysctls: >> >>sysctl dev | grep wake >> >>By setting them to 0 or 1, you can enable/disable a device waking the >>system. Note that non-ACPI devices are still not properly hooked in here >>so they won't work (i.e. sio or modems). But you can change the lid >>independently of the sleep button, for example. >> >>Also, please be sure that your system still powers off correctly when >>shutdown. I may have fixed some systems that didn't power off correctly >>as well. >> >> I did a cvsup and buildworld earlier today and I cannot shutdown -p my machine anymore. It just hangs on "Uptime: xh xm xs". (I used to be able to shutdown -p) I also cannot go into standby, nor suspend/resume. But these were not working prior What extra info do you need ? - Drew From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 01:42:10 2004 Return-Path: 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 17C4216A4CE for ; Tue, 1 Jun 2004 01:42:10 -0700 (PDT) Received: from zeus.ubbcluj.ro (NS2.UBBCluj.Ro [193.231.20.1]) by mx1.FreeBSD.org (Postfix) with SMTP id 64B2043D55 for ; Tue, 1 Jun 2004 01:42:09 -0700 (PDT) (envelope-from dan@zeus.ubbcluj.ro) Received: (qmail 20213 invoked by uid 1002); 1 Jun 2004 08:42:04 -0000 Date: Tue, 1 Jun 2004 11:42:04 +0300 From: Dan Cojocar To: freebsd-acpi@freebsd.org Message-ID: <20040601084204.GC14057@Zeus.UBBCluj.Ro> References: <20040531145641.GA74327@Zeus.UBBCluj.Ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531145641.GA74327@Zeus.UBBCluj.Ro> User-Agent: Mutt/1.4.2.1i Subject: Re: asl question X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 08:42:10 -0000 Thanks for you help. I updated my handbook and noticed that there are many new things there. Dan From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 03:26:49 2004 Return-Path: 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 175BA16A4CE for ; Tue, 1 Jun 2004 03:26:49 -0700 (PDT) Received: from fep1.cogeco.net (smtp.cogeco.net [216.221.81.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEACE43D49 for ; Tue, 1 Jun 2004 03:26:48 -0700 (PDT) (envelope-from paul.murphy@cogeco.ca) Received: from earth.upton.net (d141-23-108.home.cgocable.net [24.141.23.108]) by fep1.cogeco.net (Postfix) with SMTP id 31CFA6C1C for ; Tue, 1 Jun 2004 06:26:43 -0400 (EDT) Date: Tue, 1 Jun 2004 06:26:37 -0400 From: Paul Murphy Cc: freebsd-acpi@freebsd.org Message-Id: <20040601062637.354624a2@earth.upton.net> In-Reply-To: <20040531210236.X23630@root.org> References: <20040531145641.GA74327@Zeus.UBBCluj.Ro> <20040531140812.321e8293@earth.upton.net> <20040531210236.X23630@root.org> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__1_Jun_2004_06_26_37_-0400_sk=htx7Rd.d2s0N4" Subject: Re: asl question X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 10:26:49 -0000 --Signature=_Tue__1_Jun_2004_06_26_37_-0400_sk=htx7Rd.d2s0N4 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Mon, 31 May 2004 21:03:19 -0700 (PDT) Nate Lawson wrote: > On Mon, 31 May 2004, Paul Murphy wrote: > > On Mon, 31 May 2004 17:56:41 +0300 > > Dan Cojocar wrote: > > > > > Hello, > > > > > > What should i do, to fix an error like this: > > > > > > my.asl 884: Field (U1D3, WordAcc, NoLock, > > > Preserve) Error 1047 - ^ Access width > > > is greater than region size > > > > > > Here is my full asl: http://cs.ubbcluj.ro/~dan/my.asl > > > Thanks, > > > Dan > > > > Have a look here: > > http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt > > I want to point out that this and other FreeBSD ACPI questions are > answered in the handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > That's where I found the above link. Yes, the Handbook is first place one should look for answers. -- Cogeco ergo sum --Signature=_Tue__1_Jun_2004_06_26_37_-0400_sk=htx7Rd.d2s0N4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAvFnj2Ev+mfbss0wRAmgnAKDL8DlJDcs14Pv2smkz+JB3/XhX7gCgsndu xoPcQfrD09WI3i4LEMJ3GCk= =TR3A -----END PGP SIGNATURE----- --Signature=_Tue__1_Jun_2004_06_26_37_-0400_sk=htx7Rd.d2s0N4-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 04:14:30 2004 Return-Path: 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 08FAA16A4CF for ; Tue, 1 Jun 2004 04:14:30 -0700 (PDT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 940AF43D49 for ; Tue, 1 Jun 2004 04:14:28 -0700 (PDT) (envelope-from nike_d@cytexbg.com) Received: (qmail 85211 invoked from network); 1 Jun 2004 11:14:26 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.1.60/v4335. spamassassin: 2.63. Clear:SA:0(-4.9/8.0):. Processed in 1.77553 secs); 01 Jun 2004 11:14:26 -0000 X-Spam-Status: No, hits=-4.9 required=8.0 Received: from 213-240-206-214.ddns.cablebg.net (HELO tormentor.totalterror.net) (213.240.206.214) by mail.interbgc.com with SMTP; 1 Jun 2004 11:14:24 -0000 Received: (qmail 86198 invoked from network); 1 Jun 2004 11:10:59 -0000 Received: from unknown (HELO phobos.totalterror.net) (10.0.0.2) by tormentor.totalterror.net with SMTP; 1 Jun 2004 11:10:59 -0000 References: <20040531213045.6E8BE5D0A@ptavv.es.net> <40BC00AD.6010106@corrupt.co.nz> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Niki Denev To: Drew Broadley Date: Tue, 01 Jun 2004 14:14:41 +0300 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-phobos.totalterror.net-660-1086088481-0001"; micalg=pgp-sha1; protocol="application/pgp-signature" cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 11:14:30 -0000 This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-phobos.totalterror.net-660-1086088481-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Drew Broadley writes: > Kevin Oberman wrote: > >>>Date: Fri, 28 May 2004 00:38:32 -0700 (PDT) >>>From: Nate Lawson >>>Sender: owner-freebsd-current@freebsd.org >>> >>>I've just finished a lot of work on acpi events (GPEs). These drive >>>things like the lid switch and device wake capabilities. If your system >>>works for suspend/resume, please make sure it still behaves correctly over >>>multiple suspend/resume cycles. If you're feeling adventurous, try the >>>new wake sysctls: >>> >>>sysctl dev | grep wake >>> >>>By setting them to 0 or 1, you can enable/disable a device waking the >>>system. Note that non-ACPI devices are still not properly hooked in here >>>so they won't work (i.e. sio or modems). But you can change the lid >>>independently of the sleep button, for example. >>> >>>Also, please be sure that your system still powers off correctly when >>>shutdown. I may have fixed some systems that didn't power off correctly >>>as well. >>> >>> > I did a cvsup and buildworld earlier today and I cannot shutdown -p my > machine anymore. It just hangs on "Uptime: xh xm xs". (I used to be able > to shutdown -p) > > I also cannot go into standby, nor suspend/resume. But these were not > working prior > > What extra info do you need ? > > - Drew > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" It seems that suspend/resume works for me, but it seems to hang from time to time, when i do the susp/resume cycle several times in a row. Also with today's current my machine won't reboot anymore, it hangs too on the "Uptime: .." message. It is a IBM ThinkPad X31, with recent -CURRENT (as of 1-2 hours), dmesg, loader.conf, uname and asl can be found on : http://totalterror.net/freebsd/ --niki --=_mimegpg-phobos.totalterror.net-660-1086088481-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAvGUhHNAJ/fLbfrkRAkwEAJ4qLFel2tAst/1k8JCXWWi6a9DPiwCfY990 V2w+rXo8enCLETw07qmHWk8= =iqEf -----END PGP SIGNATURE----- --=_mimegpg-phobos.totalterror.net-660-1086088481-0001-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 08:57:20 2004 Return-Path: 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 0DE6016A4CE; Tue, 1 Jun 2004 08:57:20 -0700 (PDT) Received: from seed.net.tw (sn12.seed.net.tw [139.175.54.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id C587543D3F; Tue, 1 Jun 2004 08:57:19 -0700 (PDT) (envelope-from leafy@leafy.idv.tw) Received: from [61.59.121.140] (port=64124 helo=chihiro.leafy.idv.tw) by seed.net.tw with esmtp (Seednet 4.23:1) id 1BVBdZ-0001WN-LE; Tue, 01 Jun 2004 23:57:13 +0800 Received: from localhost (localhost [127.0.0.1]) by chihiro.leafy.idv.tw (Postfix) with ESMTP id D82CC52D; Tue, 1 Jun 2004 23:57:12 +0800 (CST) Received: from chihiro.leafy.idv.tw ([127.0.0.1]) by localhost (chihiro.leafy.idv.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01141-09; Tue, 1 Jun 2004 23:57:12 +0800 (CST) Received: by chihiro.leafy.idv.tw (Postfix, from userid 1000) id 66B6552A; Tue, 1 Jun 2004 23:57:12 +0800 (CST) Date: Tue, 1 Jun 2004 23:57:12 +0800 From: leafy To: Drew Broadley Message-ID: <20040601155712.GA7113@chihiro.leafy.idv.tw> References: <20040531213045.6E8BE5D0A@ptavv.es.net> <40BC00AD.6010106@corrupt.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline In-Reply-To: <40BC00AD.6010106@corrupt.co.nz> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at leafy.idv.tw cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 15:57:20 -0000 On Tue, Jun 01, 2004 at 04:06:05PM +1200, Drew Broadley wrote: > I did a cvsup and buildworld earlier today and I cannot shutdown -p my > machine anymore. It just hangs on "Uptime: xh xm xs". (I used to be able > to shutdown -p) > > I also cannot go into standby, nor suspend/resume. But these were not > working prior > > What extra info do you need ? > > - Drew Same here. This machine never had such problem before since 5.0 release. Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 09:23:40 2004 Return-Path: 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 87B0116A4CF for ; Tue, 1 Jun 2004 09:23:40 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3898C43D5A for ; Tue, 1 Jun 2004 09:23:40 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 27940 invoked by uid 1000); 1 Jun 2004 16:23:40 -0000 Date: Tue, 1 Jun 2004 09:23:40 -0700 (PDT) From: Nate Lawson To: leafy In-Reply-To: <20040601155712.GA7113@chihiro.leafy.idv.tw> Message-ID: <20040601092310.V27935@root.org> References: <20040531213045.6E8BE5D0A@ptavv.es.net> <40BC00AD.6010106@corrupt.co.nz> <20040601155712.GA7113@chihiro.leafy.idv.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI event testing needed X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 16:23:40 -0000 On Tue, 1 Jun 2004, leafy wrote: > On Tue, Jun 01, 2004 at 04:06:05PM +1200, Drew Broadley wrote: > > I did a cvsup and buildworld earlier today and I cannot shutdown -p my > > machine anymore. It just hangs on "Uptime: xh xm xs". (I used to be able > > to shutdown -p) > > > > I also cannot go into standby, nor suspend/resume. But these were not > > working prior > > > > What extra info do you need ? > > > > - Drew > > Same here. This machine never had such problem before since 5.0 release. Read previous replies in this thread. It appears to be an issue with a commit to /sys/i386/i386/atpic.c -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 12:30:33 2004 Return-Path: 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 21DA116A582 for ; Tue, 1 Jun 2004 12:30:33 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B5F843D54 for ; Tue, 1 Jun 2004 12:30:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4543 invoked from network); 1 Jun 2004 19:30:31 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Jun 2004 19:30:31 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i51JUQ04058615; Tue, 1 Jun 2004 15:30:26 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: acpi@FreeBSD.org Date: Tue, 1 Jun 2004 15:31:09 -0400 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406011531.09077.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: marcel@FreeBSD.org Subject: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 19:30:33 -0000 I need the patch below in order to turn on bus_config_intr() when using the I/O APICs. The original problem is that the _CRS of link devices is configured which is the PIC IRQ and thus screws up intpins when using the APIC. It basically takes bus_config_intr() out of the resource parsing code and does the config when an IRQ is allocated via bus_alloc_resource() for normal devices, and when a PCI IRQ is routed for PCI link devices. --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2004/05/06 01:05:39 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2004/05/28 10:02:20 @@ -849,15 +849,82 @@ return (0); } +static void +acpi_config_intr(device_t dev, u_int irq, int trig, int pol) +{ + + BUS_CONFIG_INTR(dev, irq, (trig == ACPI_EDGE_SENSITIVE) ? + INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol == ACPI_ACTIVE_HIGH) ? + INTR_POLARITY_HIGH : INTR_POLARITY_LOW); +} + static struct resource * acpi_alloc_resource(device_t bus, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; + struct resource *res; + ACPI_RESOURCE *ares; + ACPI_BUFFER buf; + char *curr, *last; + int i; - return (resource_list_alloc(rl, bus, child, type, rid, start, end, count, - flags)); + res = resource_list_alloc(rl, bus, child, type, rid, start, end, count, + flags); + if (res == NULL || device_get_parent(child) != bus) + return (res); + switch (type) { + case SYS_RES_IRQ: + buf.Length = ACPI_ALLOCATE_BUFFER; + if (ACPI_FAILURE((AcpiGetCurrentResources(ad->ad_handle, &buf)))) + break; + i = 0; + curr = buf.Pointer; + last = (char *)buf.Pointer + buf.Length; + while (curr < last) { + ares = (ACPI_RESOURCE *)curr; + curr += ares->Length; + switch (ares->Id) { + case ACPI_RSTYPE_END_TAG: + curr = last; + break; + case ACPI_RSTYPE_IRQ: + if (ares->Data.Irq.NumberOfInterrupts != 1) + break; + if (i != *rid) { + i++; + break; + } + KASSERT(ares->Data.Irq.Interrupts[0] == + rman_get_start(res), + ("IRQ resources do not match")); + acpi_config_intr(child, + ares->Data.Irq.Interrupts[0], + ares->Data.Irq.EdgeLevel, + ares->Data.Irq.ActiveHighLow); + break; + case ACPI_RSTYPE_EXT_IRQ: + if (ares->Data.ExtendedIrq.NumberOfInterrupts != 1) + break; + if (i != *rid) { + i++; + break; + } + KASSERT(ares->Data.ExtendedIrq.Interrupts[0] == + rman_get_start(res), + ("IRQ resources do not match")); + acpi_config_intr(child, + ares->Data.ExtendedIrq.Interrupts[0], + ares->Data.ExtendedIrq.EdgeLevel, + ares->Data.ExtendedIrq.ActiveHighLow); + break; + } + } + AcpiOsFree(buf.Pointer); + break; + } + return (res); } static int --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c 2004/05/05 19:22:26 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib.c 2004/05/28 06:38:57 @@ -121,10 +121,11 @@ ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + crsres = NULL; buf.Pointer = NULL; crsbuf.Pointer = NULL; prsbuf.Pointer = NULL; - interrupt = 255; + interrupt = PCI_INVALID_IRQ; /* ACPI numbers pins 0-3, not 1-4 like the BIOS. */ pin--; @@ -348,6 +349,7 @@ /* XXX Data.Irq and Data.ExtendedIrq are implicitly structure-copied. */ crsbuf.Pointer = NULL; + crsres = NULL; if (prsres->Id == ACPI_RSTYPE_IRQ) { resbuf.Id = ACPI_RSTYPE_IRQ; resbuf.Length = ACPI_SIZEOF_RESOURCE(ACPI_RESOURCE_IRQ); @@ -378,6 +380,7 @@ AcpiFormatException(status)); goto out; } + crsres = &resbuf; /* Return the interrupt we just routed. */ device_printf(pcib, "slot %d INT%c routed to irq %d via %s\n", @@ -386,6 +389,20 @@ interrupt = Interrupts[0]; out: + if (PCI_INTERRUPT_VALID(interrupt) && crsres != NULL) { + int trig, pol; + + if (crsres->Id == ACPI_RSTYPE_IRQ) { + trig = crsres->Data.Irq.EdgeLevel; + pol = crsres->Data.Irq.ActiveHighLow; + } else { + trig = crsres->Data.ExtendedIrq.EdgeLevel; + pol = crsres->Data.ExtendedIrq.ActiveHighLow; + } + BUS_CONFIG_INTR(dev, interrupt, (trig == ACPI_EDGE_SENSITIVE) ? + INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol == ACPI_ACTIVE_HIGH) ? + INTR_POLARITY_HIGH : INTR_POLARITY_LOW); + } if (crsbuf.Pointer != NULL) AcpiOsFree(crsbuf.Pointer); if (prsbuf.Pointer != NULL) @@ -393,6 +410,5 @@ if (buf.Pointer != NULL) AcpiOsFree(buf.Pointer); - /* XXX APIC_IO interrupt mapping? */ return_VALUE (interrupt); } --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_resource.c 2004/04/09 11:15:38 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_resource.c 2004/05/28 10:02:20 @@ -495,9 +495,6 @@ return; bus_set_resource(dev, SYS_RES_IRQ, cp->ar_nirq++, *irq, 1); - BUS_CONFIG_INTR(dev, *irq, (trig == ACPI_EDGE_SENSITIVE) ? - INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol == ACPI_ACTIVE_HIGH) ? - INTR_POLARITY_HIGH : INTR_POLARITY_LOW); } static void -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 13:24:59 2004 Return-Path: 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 EC1CC16A4CF for ; Tue, 1 Jun 2004 13:24:59 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B4D9C43D5D for ; Tue, 1 Jun 2004 13:24:59 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 29602 invoked by uid 1000); 1 Jun 2004 20:25:00 -0000 Date: Tue, 1 Jun 2004 13:25:00 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406011531.09077.jhb@FreeBSD.org> Message-ID: <20040601131817.N29571@root.org> References: <200406011531.09077.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 20:25:00 -0000 On Tue, 1 Jun 2004, John Baldwin wrote: > I need the patch below in order to turn on bus_config_intr() when using the > I/O APICs. The original problem is that the _CRS of link devices is > configured which is the PIC IRQ and thus screws up intpins when using the > APIC. It basically takes bus_config_intr() out of the resource parsing code > and does the config when an IRQ is allocated via bus_alloc_resource() for > normal devices, and when a PCI IRQ is routed for PCI link devices. I appreciate what you're trying to do but I don't like this approach. Deferring half the parsing to alloc time and moving it from acpi_resource.c results in a lot of unnecessary duplication and layering violation. The real issue you're trying to work around is that you want to defer the actual config_intr until you're sure which intr you're going to use. Some suggestions... Make polarity and trigger real resource types (sys/i386/include/resource.h) and do a bus_set_resource of them in the resource parsing code. Then in the alloc code do a bus_get_resource for them and then call BUS_CONFIG_INTR. Additionally, instead of doing the deferred BUS_CONFIG_INTR in the alloc code, it should actually be done in the MD code for bus_setup_intr(). This seems cleaner since allocating an irq resource shouldn't poke the hw until bus_setup_intr(). -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 13:37:25 2004 Return-Path: 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 AAEC516A4CE for ; Tue, 1 Jun 2004 13:37:25 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8276243D5F for ; Tue, 1 Jun 2004 13:37:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13979 invoked from network); 1 Jun 2004 20:37:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Jun 2004 20:37:24 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i51KbLN5059085; Tue, 1 Jun 2004 16:37:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Tue, 1 Jun 2004 16:38:04 -0400 User-Agent: KMail/1.6 References: <200406011531.09077.jhb@FreeBSD.org> <20040601131817.N29571@root.org> In-Reply-To: <20040601131817.N29571@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406011638.04400.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 20:37:25 -0000 On Tuesday 01 June 2004 04:25 pm, Nate Lawson wrote: > On Tue, 1 Jun 2004, John Baldwin wrote: > > I need the patch below in order to turn on bus_config_intr() when using > > the I/O APICs. The original problem is that the _CRS of link devices is > > configured which is the PIC IRQ and thus screws up intpins when using the > > APIC. It basically takes bus_config_intr() out of the resource parsing > > code and does the config when an IRQ is allocated via > > bus_alloc_resource() for normal devices, and when a PCI IRQ is routed for > > PCI link devices. > > I appreciate what you're trying to do but I don't like this approach. > Deferring half the parsing to alloc time and moving it from > acpi_resource.c results in a lot of unnecessary duplication and layering > violation. The real issue you're trying to work around is that you want > to defer the actual config_intr until you're sure which intr you're going > to use. Well, arguably it exposes an improper layering violation when bus_config_intr() was added. bus_config_intr() was probably added in the place that it is now simply because it was easier to do so. That doesn't mean it's in the correct place. I don't really consider having an ACPI-specific routine understand ACPI-specific resources. One possibility though might be to add a wrapper function to acpi_resource.c that does the bus_config_intr() on a passed-in pointer to an ACPI resource. That might reduce at least some of the duplication. > Some suggestions... Make polarity and trigger real resource types > (sys/i386/include/resource.h) and do a bus_set_resource of them in the > resource parsing code. Then in the alloc code do a bus_get_resource for > them and then call BUS_CONFIG_INTR. Additionally, instead of doing the > deferred BUS_CONFIG_INTR in the alloc code, it should actually be done in > the MD code for bus_setup_intr(). This seems cleaner since allocating an > irq resource shouldn't poke the hw until bus_setup_intr(). *sigh* Trigger and polarity are not resources, they are a property of the IRQ resource perhaps. Unfortunately, our rman(9) interface doesn't support type-specific resource attributes and I'm really not up for chainsawing rman(9) enough to get that into place. Getting this bug fixed is holding up a lot of other work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 13:37:26 2004 Return-Path: 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 F318D16A4CE for ; Tue, 1 Jun 2004 13:37:25 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC5043D5F for ; Tue, 1 Jun 2004 13:37:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13979 invoked from network); 1 Jun 2004 20:37:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Jun 2004 20:37:24 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i51KbLN5059085; Tue, 1 Jun 2004 16:37:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Tue, 1 Jun 2004 16:38:04 -0400 User-Agent: KMail/1.6 References: <200406011531.09077.jhb@FreeBSD.org> <20040601131817.N29571@root.org> In-Reply-To: <20040601131817.N29571@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406011638.04400.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 20:37:26 -0000 On Tuesday 01 June 2004 04:25 pm, Nate Lawson wrote: > On Tue, 1 Jun 2004, John Baldwin wrote: > > I need the patch below in order to turn on bus_config_intr() when using > > the I/O APICs. The original problem is that the _CRS of link devices is > > configured which is the PIC IRQ and thus screws up intpins when using the > > APIC. It basically takes bus_config_intr() out of the resource parsing > > code and does the config when an IRQ is allocated via > > bus_alloc_resource() for normal devices, and when a PCI IRQ is routed for > > PCI link devices. > > I appreciate what you're trying to do but I don't like this approach. > Deferring half the parsing to alloc time and moving it from > acpi_resource.c results in a lot of unnecessary duplication and layering > violation. The real issue you're trying to work around is that you want > to defer the actual config_intr until you're sure which intr you're going > to use. Well, arguably it exposes an improper layering violation when bus_config_intr() was added. bus_config_intr() was probably added in the place that it is now simply because it was easier to do so. That doesn't mean it's in the correct place. I don't really consider having an ACPI-specific routine understand ACPI-specific resources. One possibility though might be to add a wrapper function to acpi_resource.c that does the bus_config_intr() on a passed-in pointer to an ACPI resource. That might reduce at least some of the duplication. > Some suggestions... Make polarity and trigger real resource types > (sys/i386/include/resource.h) and do a bus_set_resource of them in the > resource parsing code. Then in the alloc code do a bus_get_resource for > them and then call BUS_CONFIG_INTR. Additionally, instead of doing the > deferred BUS_CONFIG_INTR in the alloc code, it should actually be done in > the MD code for bus_setup_intr(). This seems cleaner since allocating an > irq resource shouldn't poke the hw until bus_setup_intr(). *sigh* Trigger and polarity are not resources, they are a property of the IRQ resource perhaps. Unfortunately, our rman(9) interface doesn't support type-specific resource attributes and I'm really not up for chainsawing rman(9) enough to get that into place. Getting this bug fixed is holding up a lot of other work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 14:23:07 2004 Return-Path: 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 0234416A4CE for ; Tue, 1 Jun 2004 14:23:07 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 99BF343D5E for ; Tue, 1 Jun 2004 14:23:06 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 29964 invoked by uid 1000); 1 Jun 2004 21:23:07 -0000 Date: Tue, 1 Jun 2004 14:23:07 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406011638.04400.jhb@FreeBSD.org> Message-ID: <20040601141424.I29932@root.org> References: <200406011531.09077.jhb@FreeBSD.org> <20040601131817.N29571@root.org> <200406011638.04400.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 21:23:07 -0000 On Tue, 1 Jun 2004, John Baldwin wrote: > On Tuesday 01 June 2004 04:25 pm, Nate Lawson wrote: > > On Tue, 1 Jun 2004, John Baldwin wrote: > > > I need the patch below in order to turn on bus_config_intr() when using > > > the I/O APICs. The original problem is that the _CRS of link devices is > > > configured which is the PIC IRQ and thus screws up intpins when using the > > > APIC. It basically takes bus_config_intr() out of the resource parsing > > > code and does the config when an IRQ is allocated via > > > bus_alloc_resource() for normal devices, and when a PCI IRQ is routed for > > > PCI link devices. > > > > I appreciate what you're trying to do but I don't like this approach. > > Deferring half the parsing to alloc time and moving it from > > acpi_resource.c results in a lot of unnecessary duplication and layering > > violation. The real issue you're trying to work around is that you want > > to defer the actual config_intr until you're sure which intr you're going > > to use. > > Well, arguably it exposes an improper layering violation when > bus_config_intr() was added. bus_config_intr() was probably added in the > place that it is now simply because it was easier to do so. That doesn't > mean it's in the correct place. I don't really consider having an > ACPI-specific routine understand ACPI-specific resources. One possibility > though might be to add a wrapper function to acpi_resource.c that does the > bus_config_intr() on a passed-in pointer to an ACPI resource. That might > reduce at least some of the duplication. I still don't like this. Right now we have a single parse routine whose goal is to parse a resource object and then store the info it finds in a FreeBSD-compatible format, via bus_set_resource(). Just because bus_config_intr() doesn't stick to bus_set_resource() semantics doesn't mean we should hack acpi to bits to fix it. > > Some suggestions... Make polarity and trigger real resource types > > (sys/i386/include/resource.h) and do a bus_set_resource of them in the > > resource parsing code. Then in the alloc code do a bus_get_resource for > > them and then call BUS_CONFIG_INTR. Additionally, instead of doing the > > deferred BUS_CONFIG_INTR in the alloc code, it should actually be done in > > the MD code for bus_setup_intr(). This seems cleaner since allocating an > > irq resource shouldn't poke the hw until bus_setup_intr(). > > *sigh* Trigger and polarity are not resources, they are a property of the IRQ > resource perhaps. Unfortunately, our rman(9) interface doesn't support > type-specific resource attributes and I'm really not up for chainsawing > rman(9) enough to get that into place. Getting this bug fixed is holding up > a lot of other work. Yes, I agree they are properties of the irq resource. I'm not asking you to go the full route of implementing sub-types in rman. The simplest and backwards-compatible way to fix this is to add a MD SYS_RES_IRQ_CFG resource and set that in the parse routine. Then, in the implementation of bus_setup_intr(), look for that resource and use it for the intr configuration. The only deficiency here is that it creates a "top-level" resource type instead of a sub-type, but since there are only 6 resource types in i386/include/resource.h right now, this is hardly a huge deviation. With this change, bus_config_intr() can go away (or be a no-op for backwards API compat). This seems the simplest and cleanest approach. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 14:42:21 2004 Return-Path: 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 5679916A4CF for ; Tue, 1 Jun 2004 14:42:21 -0700 (PDT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2253143D39 for ; Tue, 1 Jun 2004 14:42:21 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26041 invoked from network); 1 Jun 2004 21:42:20 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Jun 2004 21:42:19 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i51LgFuB059488; Tue, 1 Jun 2004 17:42:15 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Tue, 1 Jun 2004 17:42:57 -0400 User-Agent: KMail/1.6 References: <200406011531.09077.jhb@FreeBSD.org> <200406011638.04400.jhb@FreeBSD.org> <20040601141424.I29932@root.org> In-Reply-To: <20040601141424.I29932@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406011742.57991.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 21:42:21 -0000 On Tuesday 01 June 2004 05:23 pm, Nate Lawson wrote: > On Tue, 1 Jun 2004, John Baldwin wrote: > > On Tuesday 01 June 2004 04:25 pm, Nate Lawson wrote: > > > On Tue, 1 Jun 2004, John Baldwin wrote: > > > > I need the patch below in order to turn on bus_config_intr() when > > > > using the I/O APICs. The original problem is that the _CRS of link > > > > devices is configured which is the PIC IRQ and thus screws up intpins > > > > when using the APIC. It basically takes bus_config_intr() out of the > > > > resource parsing code and does the config when an IRQ is allocated > > > > via > > > > bus_alloc_resource() for normal devices, and when a PCI IRQ is routed > > > > for PCI link devices. > > > > > > I appreciate what you're trying to do but I don't like this approach. > > > Deferring half the parsing to alloc time and moving it from > > > acpi_resource.c results in a lot of unnecessary duplication and > > > layering violation. The real issue you're trying to work around is > > > that you want to defer the actual config_intr until you're sure which > > > intr you're going to use. > > > > Well, arguably it exposes an improper layering violation when > > bus_config_intr() was added. bus_config_intr() was probably added in the > > place that it is now simply because it was easier to do so. That doesn't > > mean it's in the correct place. I don't really consider having an > > ACPI-specific routine understand ACPI-specific resources. One > > possibility though might be to add a wrapper function to acpi_resource.c > > that does the bus_config_intr() on a passed-in pointer to an ACPI > > resource. That might reduce at least some of the duplication. > > I still don't like this. Right now we have a single parse routine whose > goal is to parse a resource object and then store the info it finds in a > FreeBSD-compatible format, via bus_set_resource(). Just because > bus_config_intr() doesn't stick to bus_set_resource() semantics doesn't > mean we should hack acpi to bits to fix it. FreeBSD has no format for this and I don't really have time to add multiple resource types (which is what ACPI does, and probably what we will need to do eventually) to struct resource. What I have done in the current form is added some wrapper functions to acpi_resource.c (so all the magic about what rid's match up, etc. is in one file) in the patch below. > > > Some suggestions... Make polarity and trigger real resource types > > > (sys/i386/include/resource.h) and do a bus_set_resource of them in the > > > resource parsing code. Then in the alloc code do a bus_get_resource > > > for them and then call BUS_CONFIG_INTR. Additionally, instead of doing > > > the deferred BUS_CONFIG_INTR in the alloc code, it should actually be > > > done in the MD code for bus_setup_intr(). This seems cleaner since > > > allocating an irq resource shouldn't poke the hw until > > > bus_setup_intr(). > > > > *sigh* Trigger and polarity are not resources, they are a property of > > the IRQ resource perhaps. Unfortunately, our rman(9) interface doesn't > > support type-specific resource attributes and I'm really not up for > > chainsawing rman(9) enough to get that into place. Getting this bug > > fixed is holding up a lot of other work. > > Yes, I agree they are properties of the irq resource. I'm not asking you > to go the full route of implementing sub-types in rman. > > The simplest and backwards-compatible way to fix this is to add a MD > SYS_RES_IRQ_CFG resource and set that in the parse routine. Then, in the > implementation of bus_setup_intr(), look for that resource and use it for > the intr configuration. The only deficiency here is that it creates a > "top-level" resource type instead of a sub-type, but since there are only > 6 resource types in i386/include/resource.h right now, this is hardly a > huge deviation. With this change, bus_config_intr() can go away (or be a > no-op for backwards API compat). > > This seems the simplest and cleanest approach. No, I don't think this is clean. Note that ia64 needs bus_config_intr() too. In fact, that's why it was added in the first place! --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi.c 2004/05/06 01:05:39 +++ //depot/user/jhb/acpipci/dev/acpica/acpi.c 2004/06/01 14:05:57 @@ -855,9 +855,21 @@ { struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; + struct resource *res; + ACPI_RESOURCE ares; - return (resource_list_alloc(rl, bus, child, type, rid, start, end, count, - flags)); + res = resource_list_alloc(rl, bus, child, type, rid, start, end, count, + flags); + if (res == NULL || device_get_parent(child) != bus) + return (res); + switch (type) { + case SYS_RES_IRQ: + if (ACPI_FAILURE(acpi_lookup_irq_resource(dev, *rid, res, &ares))) + break; + acpi_config_intr(dev, &ares); + break; + } + return (res); } static int --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c 2004/05/05 19:22:26 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib.c 2004/06/01 14:05:57 @@ -121,10 +121,11 @@ ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + crsres = NULL; buf.Pointer = NULL; crsbuf.Pointer = NULL; prsbuf.Pointer = NULL; - interrupt = 255; + interrupt = PCI_INVALID_IRQ; /* ACPI numbers pins 0-3, not 1-4 like the BIOS. */ pin--; @@ -348,6 +349,7 @@ /* XXX Data.Irq and Data.ExtendedIrq are implicitly structure-copied. */ crsbuf.Pointer = NULL; + crsres = NULL; if (prsres->Id == ACPI_RSTYPE_IRQ) { resbuf.Id = ACPI_RSTYPE_IRQ; resbuf.Length = ACPI_SIZEOF_RESOURCE(ACPI_RESOURCE_IRQ); @@ -378,6 +380,7 @@ AcpiFormatException(status)); goto out; } + crsres = &resbuf; /* Return the interrupt we just routed. */ device_printf(pcib, "slot %d INT%c routed to irq %d via %s\n", @@ -386,6 +389,8 @@ interrupt = Interrupts[0]; out: + if (PCI_INTERRUPT_VALID(interrupt) && crsres != NULL) + acpi_config_intr(dev, crsres); if (crsbuf.Pointer != NULL) AcpiOsFree(crsbuf.Pointer); if (prsbuf.Pointer != NULL) @@ -393,6 +398,5 @@ if (buf.Pointer != NULL) AcpiOsFree(buf.Pointer); - /* XXX APIC_IO interrupt mapping? */ return_VALUE (interrupt); } --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_resource.c 2004/04/09 11:15:38 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_resource.c 2004/06/01 14:05:57 @@ -44,6 +44,88 @@ #define _COMPONENT ACPI_BUS ACPI_MODULE_NAME("RESOURCE") +ACPI_STATUS +acpi_lookup_irq_resource(device_t dev, int rid, struct resource *res, + ACPI_RESOURCE *acpi_res) +{ + ACPI_BUFFER buf; + ACPI_STATUS status; + ACPI_RESOURCE *ares; + char *curr, *last; + int i, found; + + buf.Length = ACPI_ALLOCATE_BUFFER; + status = AcpiGetCurrentResources(acpi_get_handle(dev), &buf); + if (ACPI_FAILURE(status)) + break; + i = 0; + found = 0; + curr = buf.Pointer; + last = (char *)buf.Pointer + buf.Length; + while (curr < last) { + ares = (ACPI_RESOURCE *)curr; + curr += ares->Length; + switch (ares->Id) { + case ACPI_RSTYPE_END_TAG: + curr = last; + break; + case ACPI_RSTYPE_IRQ: + if (ares->Data.Irq.NumberOfInterrupts != 1) + break; + if (i != rid) { + i++; + break; + } + KASSERT(ares->Data.Irq.Interrupts[0] == + rman_get_start(res), ("IRQ resources do not match")); + *acpi_res = *ares; + found++; + break; + case ACPI_RSTYPE_EXT_IRQ: + if (ares->Data.ExtendedIrq.NumberOfInterrupts != 1) + break; + if (i != rid) { + i++; + break; + } + KASSERT(ares->Data.ExtendedIrq.Interrupts[0] == + rman_get_start(res), ("IRQ resources do not match")); + *acpi_res = *ares; + found++; + break; + } + } + AcpiOsFree(buf.Pointer); + if (found == 0) + return (AE_NOT_FOUND); + return (AE_OK); +} + +void +acpi_config_intr(device_t dev, ACPI_RESOURCE *res) +{ + u_int irq; + int pol, trig; + + switch (res->Id) { + case ACPI_RSTYPE_IRQ: + irq = res->Data.Irq.Interrupts[0]; + trig = res->Data.Irq.EdgeLevel; + pol = res->Data.Irq.ActiveHighLow; + break; + case ACPI_RSTYPE_EXT_IRQ: + irq = res->Data.ExtendedIrq.Interrupts[0]; + trig = res->Data.ExtendedIrq.EdgeLevel; + pol = res->Data.ExtendedIrq.ActiveHighLow; + break; + default: + panic("%s: bad resource type %u", __func__, res->Id); + } + BUS_CONFIG_INTR(dev, irq, (trig == ACPI_EDGE_SENSITIVE) ? + INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol == ACPI_ACTIVE_HIGH) ? + INTR_POLARITY_HIGH : INTR_POLARITY_LOW); +} + /* * Fetch a device's resources and associate them with the device. * @@ -495,9 +577,6 @@ return; bus_set_resource(dev, SYS_RES_IRQ, cp->ar_nirq++, *irq, 1); - BUS_CONFIG_INTR(dev, *irq, (trig == ACPI_EDGE_SENSITIVE) ? - INTR_TRIGGER_EDGE : INTR_TRIGGER_LEVEL, (pol == ACPI_ACTIVE_HIGH) ? - INTR_POLARITY_HIGH : INTR_POLARITY_LOW); } static void --- //depot/vendor/freebsd/src/sys/dev/acpica/acpivar.h 2004/05/06 01:05:39 +++ //depot/user/jhb/acpipci/dev/acpica/acpivar.h 2004/06/01 14:05:57 @@ -283,6 +283,11 @@ extern ACPI_STATUS acpi_parse_resources(device_t dev, ACPI_HANDLE handle, struct acpi_parse_resource_set *set, void *arg); +ACPI_STATUS acpi_lookup_irq_resource(device_t dev, int rid, struct resource *res, + ACPI_RESOURCE *acpi_res); +void acpi_config_intr(device_t dev, ACPI_RESOURCE *res); + + /* ACPI event handling */ extern UINT32 acpi_event_power_button_sleep(void *context); extern UINT32 acpi_event_power_button_wake(void *context); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 15:05:32 2004 Return-Path: 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 0B87816A4D0 for ; Tue, 1 Jun 2004 15:05:32 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C45F443D48 for ; Tue, 1 Jun 2004 15:05:31 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 30171 invoked by uid 1000); 1 Jun 2004 22:05:32 -0000 Date: Tue, 1 Jun 2004 15:05:32 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406011742.57991.jhb@FreeBSD.org> Message-ID: <20040601145357.P30070@root.org> References: <200406011531.09077.jhb@FreeBSD.org> <200406011638.04400.jhb@FreeBSD.org> <20040601141424.I29932@root.org> <200406011742.57991.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org cc: marcel@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:05:32 -0000 On Tue, 1 Jun 2004, John Baldwin wrote: > On Tuesday 01 June 2004 05:23 pm, Nate Lawson wrote: > > I still don't like this. Right now we have a single parse routine whose > > goal is to parse a resource object and then store the info it finds in a > > FreeBSD-compatible format, via bus_set_resource(). Just because > > bus_config_intr() doesn't stick to bus_set_resource() semantics doesn't > > mean we should hack acpi to bits to fix it. > > FreeBSD has no format for this and I don't really have time to add multiple > resource types (which is what ACPI does, and probably what we will need to do > eventually) to struct resource. What I have done in the current form is > added some wrapper functions to acpi_resource.c (so all the magic about what > rid's match up, etc. is in one file) in the patch below. This is slightly better and might be acceptable as a temporary workaround if you clean it up a bit (remove duplicate rid == i checks, make style match surrounding file, etc.) But I want to make sure you actually have plans to fix bus_config_intr() and not leave this hack behind before being ok with this workaround. > > > > Some suggestions... Make polarity and trigger real resource types > > > > (sys/i386/include/resource.h) and do a bus_set_resource of them in the > > > > resource parsing code. Then in the alloc code do a bus_get_resource > > > > for them and then call BUS_CONFIG_INTR. Additionally, instead of doing > > > > the deferred BUS_CONFIG_INTR in the alloc code, it should actually be > > > > done in the MD code for bus_setup_intr(). This seems cleaner since > > > > allocating an irq resource shouldn't poke the hw until > > > > bus_setup_intr(). > > > > > > *sigh* Trigger and polarity are not resources, they are a property of > > > the IRQ resource perhaps. Unfortunately, our rman(9) interface doesn't > > > support type-specific resource attributes and I'm really not up for > > > chainsawing rman(9) enough to get that into place. Getting this bug > > > fixed is holding up a lot of other work. > > > > Yes, I agree they are properties of the irq resource. I'm not asking you > > to go the full route of implementing sub-types in rman. > > > > The simplest and backwards-compatible way to fix this is to add a MD > > SYS_RES_IRQ_CFG resource and set that in the parse routine. Then, in the > > implementation of bus_setup_intr(), look for that resource and use it for > > the intr configuration. The only deficiency here is that it creates a > > "top-level" resource type instead of a sub-type, but since there are only > > 6 resource types in i386/include/resource.h right now, this is hardly a > > huge deviation. With this change, bus_config_intr() can go away (or be a > > no-op for backwards API compat). > > > > This seems the simplest and cleanest approach. > > No, I don't think this is clean. Note that ia64 needs bus_config_intr() too. > In fact, that's why it was added in the first place! I understand this but it doesn't have anything to do with my suggestion. sys/amd64/include/resource.h:#define SYS_RES_IRQ 1 /* interrupt lines */ sys/amd64/include/resource.h:#define SYS_RES_DRQ 2 /* isa dma lines */ sys/amd64/include/resource.h:#define SYS_RES_MEMORY 3 /* i/o memory */ sys/amd64/include/resource.h:#define SYS_RES_IOPORT 4 /* i/o ports */ sys/i386/include/resource.h:#define SYS_RES_IRQ 1 /* interrupt lines */ sys/i386/include/resource.h:#define SYS_RES_DRQ 2 /* isa dma lines */ sys/i386/include/resource.h:#define SYS_RES_MEMORY 3 /* i/o memory */ sys/i386/include/resource.h:#define SYS_RES_IOPORT 4 /* i/o ports */ sys/ia64/include/resource.h:#define SYS_RES_IRQ 1 /* interrupt lines */ sys/ia64/include/resource.h:#define SYS_RES_DRQ 2 /* isa dma lines */ sys/ia64/include/resource.h:#define SYS_RES_MEMORY 3 /* i/o memory */ sys/ia64/include/resource.h:#define SYS_RES_IOPORT 4 /* i/o ports */ Add a #define SYS_RES_IRQ_CFG to each of these files. Have acpi set it on child devices. Only implement code to read these "resource types" in {i386,amd64,ia64} bus_setup_intr() implementations. Other archs will get ENOENT if they try to read them, which would be a bug anyway. These are all MD files. The impact of this approach is only 1 define in the $ARCH .h files, 2 lines of code in $ARCH/$ARCH/nexus.c to call bus_get_resource() and intr_config_intr(), and 2 lines of code in acpi_parse_resources to call bus_set_resource(). This is for only 3 archs. Are you thinking it's something bigger than this? -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 15:11:10 2004 Return-Path: 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 A891216A4CE; Tue, 1 Jun 2004 15:11:10 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24DE843D58; Tue, 1 Jun 2004 15:11:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i51MB9jH021195; Tue, 1 Jun 2004 15:11:09 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i51MB9kw021194; Tue, 1 Jun 2004 15:11:09 -0700 (PDT) (envelope-from marcel) Date: Tue, 1 Jun 2004 15:11:09 -0700 From: Marcel Moolenaar To: John Baldwin Message-ID: <20040601221109.GA21063@ns1.xcllnt.net> References: <200406011531.09077.jhb@FreeBSD.org> <200406011638.04400.jhb@FreeBSD.org> <20040601141424.I29932@root.org> <200406011742.57991.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406011742.57991.jhb@FreeBSD.org> User-Agent: Mutt/1.5.5.1i cc: freebsd-acpi@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:11:10 -0000 On Tue, Jun 01, 2004 at 05:42:57PM -0400, John Baldwin wrote: > > > > > I need the patch below in order to turn on bus_config_intr() when > > > > > using the I/O APICs. *snip* > > > > I appreciate what you're trying to do but I don't like this approach. *snip* > > > Well, arguably it exposes an improper layering violation when > > > bus_config_intr() was added. *snip* > > I still don't like this. *snip* > FreeBSD has no format for this and I don't really have time to add multiple > resource types (which is what ACPI does, and probably what we will need to do > eventually) to struct resource. Ok, let's relax for a minute. Clearly, the addition of bus_config_intr() was done in a biggest-bang-for-the-buck approach and I think we can assume for now that it's there in a way that isn't easily extensible. So, the root problem now is that we need to consume the ACPI info in a way that makes it available for later use, i.e., when we actually allocate the IRQ resource. The solution needs to be simple so that jhb@ can close the immediate problem and it should also be a step in the right direction, or at least not a step in the opposite direction, so that njl@ doesn't get cornered by it at some later time. Let me give the numbers: o We need 2 bits for the polarity, o We need 2 bits for the trigger mode, o r_flags is 32 bits of which only 16 are in use. Can we not stick the IRQ properties in r_flags, just like we stick the alignment properties there, remove bus_config_intr() and make sure the MD backend queries the flags for polarity and trigger (0 values will mean "default" and thus preserve backward compatibility)? This change should only affect 2 places: the place where we set the resource and the place where we actually install the interrupt and its handler. It's roughly in line with what jhb@ wants to achieve and I think it removes the code that njl@ is objecting to the most, right? Oh, and it's not intended to be pretty. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 15:29:13 2004 Return-Path: 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 3B88F16A4D0 for ; Tue, 1 Jun 2004 15:29:13 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1718143D41 for ; Tue, 1 Jun 2004 15:29:13 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 30284 invoked by uid 1000); 1 Jun 2004 22:29:14 -0000 Date: Tue, 1 Jun 2004 15:29:14 -0700 (PDT) From: Nate Lawson To: Marcel Moolenaar In-Reply-To: <20040601221109.GA21063@ns1.xcllnt.net> Message-ID: <20040601152758.L30281@root.org> References: <200406011531.09077.jhb@FreeBSD.org> <200406011638.04400.jhb@FreeBSD.org> <20040601141424.I29932@root.org> <200406011742.57991.jhb@FreeBSD.org> <20040601221109.GA21063@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org cc: John Baldwin Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:29:13 -0000 On Tue, 1 Jun 2004, Marcel Moolenaar wrote: > On Tue, Jun 01, 2004 at 05:42:57PM -0400, John Baldwin wrote: > > > > > > I need the patch below in order to turn on bus_config_intr() when > > > > > > using the I/O APICs. > *snip* > > > > > I appreciate what you're trying to do but I don't like this approach. > *snip* > > > > Well, arguably it exposes an improper layering violation when > > > > bus_config_intr() was added. > *snip* > > > I still don't like this. > *snip* > > FreeBSD has no format for this and I don't really have time to add multiple > > resource types (which is what ACPI does, and probably what we will need to do > > eventually) to struct resource. > > Ok, let's relax for a minute. Clearly, the addition of bus_config_intr() > was done in a biggest-bang-for-the-buck approach and I think we can > assume for now that it's there in a way that isn't easily extensible. > > So, the root problem now is that we need to consume the ACPI info in > a way that makes it available for later use, i.e., when we actually > allocate the IRQ resource. The solution needs to be simple so that > jhb@ can close the immediate problem and it should also be a step in > the right direction, or at least not a step in the opposite direction, > so that njl@ doesn't get cornered by it at some later time. Yes, exactly. > Let me give the numbers: > o We need 2 bits for the polarity, > o We need 2 bits for the trigger mode, > o r_flags is 32 bits of which only 16 are in use. > > Can we not stick the IRQ properties in r_flags, just like we > stick the alignment properties there, remove bus_config_intr() > and make sure the MD backend queries the flags for polarity and > trigger (0 values will mean "default" and thus preserve backward > compatibility)? > > This change should only affect 2 places: the place where we set > the resource and the place where we actually install the interrupt > and its handler. It's roughly in line with what jhb@ wants to achieve > and I think it removes the code that njl@ is objecting to the most, > right? This is an excellent idea. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 15:35:27 2004 Return-Path: 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 8F00F16A4CE; Tue, 1 Jun 2004 15:35:27 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24EC243D48; Tue, 1 Jun 2004 15:35:27 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i51MXF3D016677; Tue, 1 Jun 2004 16:33:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jun 2004 16:33:16 -0600 (MDT) Message-Id: <20040601.163316.88476133.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20040601221109.GA21063@ns1.xcllnt.net> References: <20040601141424.I29932@root.org> <200406011742.57991.jhb@FreeBSD.org> <20040601221109.GA21063@ns1.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@FreeBSD.ORG cc: jhb@FreeBSD.ORG Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:35:27 -0000 In message: <20040601221109.GA21063@ns1.xcllnt.net> Marcel Moolenaar writes: : On Tue, Jun 01, 2004 at 05:42:57PM -0400, John Baldwin wrote: : > > > > > I need the patch below in order to turn on bus_config_intr() when : > > > > > using the I/O APICs. : *snip* : > > > > I appreciate what you're trying to do but I don't like this approach. : *snip* : > > > Well, arguably it exposes an improper layering violation when : > > > bus_config_intr() was added. : *snip* : > > I still don't like this. : *snip* : > FreeBSD has no format for this and I don't really have time to add multiple : > resource types (which is what ACPI does, and probably what we will need to do : > eventually) to struct resource. : : Ok, let's relax for a minute. Clearly, the addition of bus_config_intr() : was done in a biggest-bang-for-the-buck approach and I think we can : assume for now that it's there in a way that isn't easily extensible. : : So, the root problem now is that we need to consume the ACPI info in : a way that makes it available for later use, i.e., when we actually : allocate the IRQ resource. The solution needs to be simple so that : jhb@ can close the immediate problem and it should also be a step in : the right direction, or at least not a step in the opposite direction, : so that njl@ doesn't get cornered by it at some later time. : : Let me give the numbers: : o We need 2 bits for the polarity, : o We need 2 bits for the trigger mode, : o r_flags is 32 bits of which only 16 are in use. : : Can we not stick the IRQ properties in r_flags, just like we : stick the alignment properties there, remove bus_config_intr() : and make sure the MD backend queries the flags for polarity and : trigger (0 values will mean "default" and thus preserve backward : compatibility)? : : This change should only affect 2 places: the place where we set : the resource and the place where we actually install the interrupt : and its handler. It's roughly in line with what jhb@ wants to achieve : and I think it removes the code that njl@ is objecting to the most, : right? : : Oh, and it's not intended to be pretty. I like it. Or should I say "Given that we're looking for an evolutionary change to shoe horn this in, I think it is better than any of the other ugly kludges." Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 08:04:27 2004 Return-Path: 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 ADF4D16A4CE for ; Wed, 2 Jun 2004 08:04:27 -0700 (PDT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB9C43D2F for ; Wed, 2 Jun 2004 08:04:27 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28988 invoked from network); 2 Jun 2004 15:04:26 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Jun 2004 15:04:26 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i52F4E7i064970; Wed, 2 Jun 2004 11:04:17 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Wed, 2 Jun 2004 11:04:59 -0400 User-Agent: KMail/1.6 References: <20040601141424.I29932@root.org> <20040601221109.GA21063@ns1.xcllnt.net> <20040601.163316.88476133.imp@bsdimp.com> In-Reply-To: <20040601.163316.88476133.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021104.59860.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 15:04:27 -0000 On Tuesday 01 June 2004 06:33 pm, M. Warner Losh wrote: > In message: <20040601221109.GA21063@ns1.xcllnt.net> > > Marcel Moolenaar writes: > : On Tue, Jun 01, 2004 at 05:42:57PM -0400, John Baldwin wrote: > : > > > > > I need the patch below in order to turn on bus_config_intr() > : > > > > > when using the I/O APICs. > : > : *snip* > : > : > > > > I appreciate what you're trying to do but I don't like this > : > > > > approach. > : > : *snip* > : > : > > > Well, arguably it exposes an improper layering violation when > : > > > bus_config_intr() was added. > : > : *snip* > : > : > > I still don't like this. > : > : *snip* > : > : > FreeBSD has no format for this and I don't really have time to add > : > multiple resource types (which is what ACPI does, and probably what we > : > will need to do eventually) to struct resource. > : > : Ok, let's relax for a minute. Clearly, the addition of bus_config_intr() > : was done in a biggest-bang-for-the-buck approach and I think we can > : assume for now that it's there in a way that isn't easily extensible. > : > : So, the root problem now is that we need to consume the ACPI info in > : a way that makes it available for later use, i.e., when we actually > : allocate the IRQ resource. The solution needs to be simple so that > : jhb@ can close the immediate problem and it should also be a step in > : the right direction, or at least not a step in the opposite direction, > : so that njl@ doesn't get cornered by it at some later time. > : > : Let me give the numbers: > : o We need 2 bits for the polarity, > : o We need 2 bits for the trigger mode, > : o r_flags is 32 bits of which only 16 are in use. > : > : Can we not stick the IRQ properties in r_flags, just like we > : stick the alignment properties there, remove bus_config_intr() > : and make sure the MD backend queries the flags for polarity and > : trigger (0 values will mean "default" and thus preserve backward > : compatibility)? > : > : This change should only affect 2 places: the place where we set > : the resource and the place where we actually install the interrupt > : and its handler. It's roughly in line with what jhb@ wants to achieve > : and I think it removes the code that njl@ is objecting to the most, > : right? > : > : Oh, and it's not intended to be pretty. > > I like it. Or should I say "Given that we're looking for an > evolutionary change to shoe horn this in, I think it is better than > any of the other ugly kludges." The only PITA is that when we route PCI interrupts we have to push the trigger/polarity back to the alloc_resource() that called route_interrupt(). I guess we could just ignore ACPIs settings and hardcode level/low for PCI interrupts. What I was thinking about on the way home, btw, was to have struct resource be a base class sort of for resoures, and to have an irq_resource, mem_resource, dma_resource, etc. Each class would have an alloc() function that returns a template that is handed to resource_list_alloc() so that you would do something like: struct resource *res; res = irq_resource_alloc(TRIGGER_LEVEL, POLARITY_LOW); bus_alloc_resource(..., res); And bus_alloc_resource() just fills out the common struct resource fields. But really alloc_resource() should be overridden per type as well so that you could make 'prefetchable' and 'alignment' properties of just memory resources, but both of those factor into the alloc() algorithm. I guess we just need a much better resource abstraction. *sigh* -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 10:57:38 2004 Return-Path: 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 6E31716A4D1 for ; Wed, 2 Jun 2004 10:57:38 -0700 (PDT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AE3C43D4C for ; Wed, 2 Jun 2004 10:57:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5895 invoked from network); 2 Jun 2004 17:57:38 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Jun 2004 17:57:37 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i52HvXnP066144 for ; Wed, 2 Jun 2004 13:57:33 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Wed, 2 Jun 2004 13:58:17 -0400 User-Agent: KMail/1.6 References: <20040601141424.I29932@root.org> <20040601.163316.88476133.imp@bsdimp.com> <200406021104.59860.jhb@FreeBSD.org> In-Reply-To: <200406021104.59860.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406021358.17521.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 17:57:38 -0000 On Wednesday 02 June 2004 11:04 am, John Baldwin wrote: > > I like it. Or should I say "Given that we're looking for an > > evolutionary change to shoe horn this in, I think it is better than > > any of the other ugly kludges." > > The only PITA is that when we route PCI interrupts we have to push the > trigger/polarity back to the alloc_resource() that called > route_interrupt(). I guess we could just ignore ACPIs settings and hardcode > level/low for PCI interrupts. What I was thinking about on the way home, > btw, was to have struct resource be a base class sort of for resoures, and > to have an irq_resource, mem_resource, dma_resource, etc. Each class would > have an alloc() function that returns a template that is handed to > resource_list_alloc() so that you would do something like: > > struct resource *res; > > res = irq_resource_alloc(TRIGGER_LEVEL, POLARITY_LOW); > bus_alloc_resource(..., res); > > And bus_alloc_resource() just fills out the common struct resource fields. > But really alloc_resource() should be overridden per type as well so that > you could make 'prefetchable' and 'alignment' properties of just memory > resources, but both of those factor into the alloc() algorithm. I guess we > just need a much better resource abstraction. *sigh* Ok, summary of PITAs after an hour or so of looking into it: - For the PIC mode on i386, we use bus_config_intr() after bus_setup_intr() to set the interrupt to level/low. This can be worked around by deferring handler setup until after acpica_machdep_init() and calling AcpiEnableSubsystem() twice. - There is no way (currently) to get a pointer to the resource structure associated with rid X w/o calling bus_alloc_resource(). In fact, there is no resource structure in which to place the IRQ configuration flags until bus_alloc_resource(), thus for the bus_config_intr() that sets the mode for the SCI for PIC mode above there is no resource (once you defer the interrupt setup) and for all of the resources set via bus_set_resource() in acpi_parse_resources() there is no resource to set the flags in, so that info is lost unless we also hack on the resource list items to add flag members and change that API to allow for flags to be passed around. - sys/rman.h now depends on sys/bus.h being included before it - The above mentioned PITA regarding having to rework the route_interrupt() interface since we don't have a resource to stick the flags in yet. I really don't want to spend a lot of time implementing all this. Does somebody else want to do this? The change I posted earlier is a _lot_ simpler and smaller. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 12:02:23 2004 Return-Path: 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 9048516A4CE for ; Wed, 2 Jun 2004 12:02:23 -0700 (PDT) Received: from clever.eusc.inter.net (clever.eusc.inter.net [213.73.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C2BC43D2D for ; Wed, 2 Jun 2004 12:02:23 -0700 (PDT) (envelope-from plexus@snafu.de) Received: from pd9e0e3b9.dip.t-dialin.net ([217.224.227.185] helo=[192.168.0.2]) by clever.eusc.inter.net with asmtp (Exim 3.36 #4) id 1BVb0H-0006gi-00 for acpi@freebsd.org; Wed, 02 Jun 2004 21:02:22 +0200 Message-ID: <40BE243D.1050909@snafu.de> Date: Wed, 02 Jun 2004 21:02:21 +0200 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Success report: 5.2 CURRENT on a IBM R51 1830 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 19:02:23 -0000 Hello! I would like to let you know, that ACPI works well on my new IBM R51 1830 BRG. S3 is working, Sound and NIC too. Here is the output of sysctl hw.acpi: 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: 5 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_poweroff: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.throttle_max: 8 hw.acpi.cpu.throttle_state: 8 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_history: 367835/0 0/0 0/0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 3192 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3647 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3672 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 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 hw.acpi.acline: 1 Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 12:14:59 2004 Return-Path: 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 137D116A4CE for ; Wed, 2 Jun 2004 12:14:59 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD2843D5A for ; Wed, 2 Jun 2004 12:14:58 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Wed, 02 Jun 2004 12:14:57 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BBA1F5D09; Wed, 2 Jun 2004 12:14:57 -0700 (PDT) To: "Oliver B. Fischer" In-reply-to: Your message of "Wed, 02 Jun 2004 21:02:21 +0200." <40BE243D.1050909@snafu.de> Date: Wed, 02 Jun 2004 12:14:57 -0700 From: "Kevin Oberman" Message-Id: <20040602191457.BBA1F5D09@ptavv.es.net> cc: acpi@freebsd.org Subject: Re: Success report: 5.2 CURRENT on a IBM R51 1830 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 19:14:59 -0000 > Date: Wed, 02 Jun 2004 21:02:21 +0200 > From: "Oliver B. Fischer" > Sender: owner-freebsd-acpi@freebsd.org > > Hello! > > I would like to let you know, that ACPI works well on my new IBM R51 > 1830 BRG. S3 is working, Sound and NIC too. Congratulations! I do have a couple of questions. 1. What version of FreeBSD (cvsup time if CURRENT)? Your sysctl output indicates that if MAY be a few days old. 2. Does sound work correctly after S3? Try playing something with xmms or totem whatever player as long as it's got a time display and see if the clock advances one minute in one minute or in something like 55 seconds. Does the sound seem a bit high pitched? Just curious about what you are seeing vs. what I am seeing. For me and my T30, everything seems to be working except the sound problem described above. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 14:07:04 2004 Return-Path: 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 AEF8B16A4CE for ; Wed, 2 Jun 2004 14:07:04 -0700 (PDT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A95E43D1D for ; Wed, 2 Jun 2004 14:07:04 -0700 (PDT) (envelope-from plexus@snafu.de) Received: from pd95173db.dip.t-dialin.net ([217.81.115.219] helo=[192.168.0.2]) by smart.eusc.inter.net with asmtp (Exim 3.36 #4) id 1BVcwx-0007Fi-00; Wed, 02 Jun 2004 23:07:03 +0200 Message-ID: <40BE4177.4020806@snafu.de> Date: Wed, 02 Jun 2004 23:07:03 +0200 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20040602191457.BBA1F5D09@ptavv.es.net> In-Reply-To: <20040602191457.BBA1F5D09@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Success report: 5.2 CURRENT on a IBM R51 1830 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 21:07:04 -0000 Kevin Oberman wrote: > 1. What version of FreeBSD (cvsup time if CURRENT)? Your sysctl output > indicates that if MAY be a few days old. My last cvs up is about one week ago. > 2. Does sound work correctly after S3? Try playing something with xmms > or totem whatever player as long as it's got a time display and see > if the clock advances one minute in one minute or in something like > 55 seconds. Does the sound seem a bit high pitched? Yes, sound works also after S3. > Just curious about what you are seeing vs. what I am seeing. For me and > my T30, everything seems to be working except the sound problem I guess, that the ACPI part of my BIOS has been improved. Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 16:27:17 2004 Return-Path: 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 EF1A016A4CE for ; Wed, 2 Jun 2004 16:27:17 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id B6F4143D41 for ; Wed, 2 Jun 2004 16:27:17 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 38357 invoked by uid 1000); 2 Jun 2004 23:27:19 -0000 Date: Wed, 2 Jun 2004 16:27:19 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406021358.17521.jhb@FreeBSD.org> Message-ID: <20040602160338.T38138@root.org> References: <20040601141424.I29932@root.org> <20040601.163316.88476133.imp@bsdimp.com> <200406021358.17521.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 23:27:18 -0000 On Wed, 2 Jun 2004, John Baldwin wrote: > Ok, summary of PITAs after an hour or so of looking into it: I appreciate your efforts. Just to recap, we're trying to work around an API design problem with bus_config_intr(). > - For the PIC mode on i386, we use bus_config_intr() after bus_setup_intr() to > set the interrupt to level/low. This can be worked around by deferring > handler setup until after acpica_machdep_init() and calling > AcpiEnableSubsystem() twice. > - There is no way (currently) to get a pointer to the resource structure > associated with rid X w/o calling bus_alloc_resource(). In fact, there is > no resource structure in which to place the IRQ configuration flags until > bus_alloc_resource(), thus for the bus_config_intr() that sets the mode for > the SCI for PIC mode above there is no resource (once you defer the > interrupt setup) and for all of the resources set via bus_set_resource() in > acpi_parse_resources() there is no resource to set the flags in, so that > info is lost unless we also hack on the resource list items to add flag > members and change that API to allow for flags to be passed around. How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and adding an "int flags" field to struct resource_list_entry? Or break the API now and add flags to the normal bus_{get,set}_resource(). This is going to be needed for other resource types in the future that have modes. > I really don't want to spend a lot of time implementing all this. Does > somebody else want to do this? The change I posted earlier is a _lot_ > simpler and smaller. Just because bus_config_intr doesn't have a counterpart for storing the config doesn't mean the right thing to do is to force every user of it to re-parse/fetch the settings they already set. I understand this is a pain but the time to contain the damage is now rather than letting it spread more. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 17:11:56 2004 Return-Path: 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 E253A16A4CE; Wed, 2 Jun 2004 17:11:55 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A39443D49; Wed, 2 Jun 2004 17:11:55 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i5308IOY036855; Wed, 2 Jun 2004 18:08:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jun 2004 18:08:19 -0600 (MDT) Message-Id: <20040602.180819.122454942.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040602160338.T38138@root.org> References: <20040601.163316.88476133.imp@bsdimp.com> <200406021358.17521.jhb@FreeBSD.org> <20040602160338.T38138@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 00:11:56 -0000 In message: <20040602160338.T38138@root.org> Nate Lawson writes: : > - For the PIC mode on i386, we use bus_config_intr() after bus_setup_intr() to : > set the interrupt to level/low. This can be worked around by deferring : > handler setup until after acpica_machdep_init() and calling : > AcpiEnableSubsystem() twice. : > - There is no way (currently) to get a pointer to the resource structure : > associated with rid X w/o calling bus_alloc_resource(). In fact, there is : > no resource structure in which to place the IRQ configuration flags until : > bus_alloc_resource(), thus for the bus_config_intr() that sets the mode for : > the SCI for PIC mode above there is no resource (once you defer the : > interrupt setup) and for all of the resources set via bus_set_resource() in : > acpi_parse_resources() there is no resource to set the flags in, so that : > info is lost unless we also hack on the resource list items to add flag : > members and change that API to allow for flags to be passed around. : : How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and : adding an "int flags" field to struct resource_list_entry? Or break the : API now and add flags to the normal bus_{get,set}_resource(). This is : going to be needed for other resource types in the future that have modes. What sort of resources have modes (apart from the polarity of interrupts)? What does the 'flags' mean? Who is allowed to set it? It would likely be better to have an API that allows mutliple parties to set it. The PCI bus code sets the IRQ number or requests the higher level nodes in the device tree to route an interrupt for it, which it then sets. The ordering is not quite right to allow for the flags to be set in the initial bus_set_resource. The interrupt routing things also tend to not have good knowledge of who the appropriate ultimate customer of the interrupt is as well. So there are problems down this path as well. I know there is prefechtable vs non-prefetchable memory. However, that is allocated in a different way (they come out of different pools at the bridge level). Interrupts come from a common pool and it is how they are configured that is magic. : > I really don't want to spend a lot of time implementing all this. Does : > somebody else want to do this? The change I posted earlier is a _lot_ : > simpler and smaller. : : Just because bus_config_intr doesn't have a counterpart for storing the : config doesn't mean the right thing to do is to force every user of it to : re-parse/fetch the settings they already set. I understand this is a pain : but the time to contain the damage is now rather than letting it spread : more. Not necessarily true. It may be better to deal with this in an ad-hoc way now to make progress and deal with the resource model short comings in the future. Especially given how close we are to the 5.x branch point. It might make good sense to have an expedient fix as well as a long term plan. The bigger problem is that interrupts are an afterthough in our resource allocation mechanism. They just barely fit into the scheme we have now, and not very well. Two step allocation/activation is different than other resources (since you have to give an ISR rather than just calling bus_activiate_resource). Forcing all resources to behave like interrupts so we can use the common underlying mechanism might not be the right thing either. Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 2 17:30:55 2004 Return-Path: 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 4321016A4D0 for ; Wed, 2 Jun 2004 17:30:55 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1ED9143D48 for ; Wed, 2 Jun 2004 17:30:55 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 38670 invoked by uid 1000); 3 Jun 2004 00:30:56 -0000 Date: Wed, 2 Jun 2004 17:30:56 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040602.180819.122454942.imp@bsdimp.com> Message-ID: <20040602171730.Q38563@root.org> References: <20040601.163316.88476133.imp@bsdimp.com> <200406021358.17521.jhb@FreeBSD.org> <20040602.180819.122454942.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 00:30:55 -0000 On Wed, 2 Jun 2004, M. Warner Losh wrote: > In message: <20040602160338.T38138@root.org> > Nate Lawson writes: > : How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and > : adding an "int flags" field to struct resource_list_entry? Or break the > : API now and add flags to the normal bus_{get,set}_resource(). This is > : going to be needed for other resource types in the future that have modes. > > What sort of resources have modes (apart from the polarity of > interrupts)? Rman has other types (like meter) and those units may have some differentiating factor. Memory may be tuned to be uncacheable, write-through, or other modes. For instance, instead of setting MTRRs, being able to set a parameter for a given resource might be a more general way to do this kind of thing. I don't have a good idea about the future of this, just that per-resource attributes (in some form) are the right way to capture the polarity/trigger and may be generally useful in the future. > What does the 'flags' mean? Who is allowed to set it? It's a per-resource attribute, interpreted by anyone who knows more about the specific resource (i.e. the bus). Anyone is allowed to set it that can call the API, just like every other bus function. > It would likely be better to have an API that allows mutliple parties > to set it. Sure, that's the model of having a separate "set attribute" function. > The PCI bus code sets the IRQ number or requests the > higher level nodes in the device tree to route an interrupt for it, > which it then sets. The ordering is not quite right to allow for the > flags to be set in the initial bus_set_resource. Ok, then this should be separate. > : > I really don't want to spend a lot of time implementing all this. Does > : > somebody else want to do this? The change I posted earlier is a _lot_ > : > simpler and smaller. > : > : Just because bus_config_intr doesn't have a counterpart for storing the > : config doesn't mean the right thing to do is to force every user of it to > : re-parse/fetch the settings they already set. I understand this is a pain > : but the time to contain the damage is now rather than letting it spread > : more. > > Not necessarily true. It may be better to deal with this in an ad-hoc > way now to make progress and deal with the resource model short > comings in the future. Especially given how close we are to the 5.x > branch point. It might make good sense to have an expedient fix as > well as a long term plan. I agree this is shaping up to be a short/long term kind of thing. Let me think a little about the last version of jhb's patch, see if I can improve it, and get back to you within a day. One problem with his approach is it splits acpi resource parsing due to a lower-level API deficiency and that makes maintaining the resource code harder. In fact, my local rman work has shown me that we need to be improving things before they split further. > The bigger problem is that interrupts are an afterthough in our > resource allocation mechanism. They just barely fit into the scheme > we have now, and not very well. Two step allocation/activation is > different than other resources (since you have to give an ISR rather > than just calling bus_activiate_resource). Forcing all resources to > behave like interrupts so we can use the common underlying mechanism > might not be the right thing either. Yes, this is a really big architectural issue. I was hoping we could come up with a general hack for passing private information from parse time to consumers downstream. You're right that we should work on this for the 6.x timeframe. I also found I needed multi-pass probe/attach for the rman work but recreated it locally within the acpi probe. I'm still holding out for a low-impact way of passing info from parse time to alloc time. Perhaps I can use an ACPI ivar. I'll get back to you. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 05:49:32 2004 Return-Path: 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 88B6316A4CE for ; Thu, 3 Jun 2004 05:49:32 -0700 (PDT) Received: from zeus.ubbcluj.ro (Ns2.UBBCluj.Ro [193.231.20.1]) by mx1.FreeBSD.org (Postfix) with SMTP id 8357543D46 for ; Thu, 3 Jun 2004 05:49:31 -0700 (PDT) (envelope-from dan@zeus.ubbcluj.ro) Received: (qmail 68689 invoked by uid 1002); 3 Jun 2004 12:49:30 -0000 Date: Thu, 3 Jun 2004 15:49:30 +0300 From: Dan Cojocar To: freebsd-acpi@freebsd.org Message-ID: <20040603124930.GA58885@Zeus.UBBCluj.Ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: hp ze4560 thermal problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 12:49:32 -0000 Hello, I have a hp ze4560us notebook, i'm running current and i'm having problems with cooling system. The cooler is running nonstop but the reported temperature is always high, beetween 70 and 75C and in win the average temparature is 55-60C and the fan is running from time to time, and if i increase the ec.pool_timeout to 1000 then i will get a message like this: WARNING - current temperature (138.0C) exceeds safe limits Followed by a shutdown, i get this only when ec.pool_timeout is set to 1000, if i let the default value i will get AE_NO_HARDWARE_RESPONSE and everything seems ok, only that the temperature is around 70C and the fan is running :(. I noticed that my hw.acpi.thermal.tz0.active is set -1 and i can't change this value, what is this meaning? Please see my dmesg, asl dump, and sysctl -a hw.acpi here: http://cs.ubbcluj.ro/~dan/acpi/ Please note that i have the last bios version for this hp model. I apreciate all your help, thanks. Dan Ps. please excuse my english From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 06:17:01 2004 Return-Path: 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 E15D916A4CE for ; Thu, 3 Jun 2004 06:17:00 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FCB543D58 for ; Thu, 3 Jun 2004 06:17:00 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2007 invoked from network); 3 Jun 2004 13:17:00 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Jun 2004 13:16:59 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i53DGtev072791; Thu, 3 Jun 2004 09:16:56 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Thu, 3 Jun 2004 09:17:36 -0400 User-Agent: KMail/1.6 References: <20040601141424.I29932@root.org> <200406021358.17521.jhb@FreeBSD.org> <20040602160338.T38138@root.org> In-Reply-To: <20040602160338.T38138@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406030917.36901.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 13:17:01 -0000 On Wednesday 02 June 2004 07:27 pm, Nate Lawson wrote: > On Wed, 2 Jun 2004, John Baldwin wrote: > > Ok, summary of PITAs after an hour or so of looking into it: > > I appreciate your efforts. Just to recap, we're trying to work around an > API design problem with bus_config_intr(). Well, it depends. See, using the existing API, I can make it work now with a small change. Here's some more food for thought. Specifically we are dealing with properties of an IRQ resource, correct? Now, the flags in struct resource now are provided by the driver as part of the request (align to this many bytes, I want it to be prefetchable, etc.). The properties of the actual hardware interrupt line are _not_ provided by the driver, but by the firmware. Now, what's another attribute about an IRQ resource that is provided by the firmware/BIOS. PCI interrupt routing! Yes, and where do we go ask the firmware for that information? bus_alloc_resource! So, we have a working model now. > > > - For the PIC mode on i386, we use bus_config_intr() after > > bus_setup_intr() to set the interrupt to level/low. This can be worked > > around by deferring handler setup until after acpica_machdep_init() and > > calling > > AcpiEnableSubsystem() twice. > > - There is no way (currently) to get a pointer to the resource structure > > associated with rid X w/o calling bus_alloc_resource(). In fact, there > > is no resource structure in which to place the IRQ configuration flags > > until bus_alloc_resource(), thus for the bus_config_intr() that sets the > > mode for the SCI for PIC mode above there is no resource (once you defer > > the interrupt setup) and for all of the resources set via > > bus_set_resource() in acpi_parse_resources() there is no resource to set > > the flags in, so that info is lost unless we also hack on the resource > > list items to add flag members and change that API to allow for flags to > > be passed around. > > How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and > adding an "int flags" field to struct resource_list_entry? Or break the > API now and add flags to the normal bus_{get,set}_resource(). This is > going to be needed for other resource types in the future that have modes. Feel free to work on it. The users with machines that freeze because the APIC driver can't support config_intr() yet will just have to wait. I've got to work on putting out preemption fires anyway. *sigh* > > I really don't want to spend a lot of time implementing all this. Does > > somebody else want to do this? The change I posted earlier is a _lot_ > > simpler and smaller. > > Just because bus_config_intr doesn't have a counterpart for storing the > config doesn't mean the right thing to do is to force every user of it to > re-parse/fetch the settings they already set. I understand this is a pain > but the time to contain the damage is now rather than letting it spread > more. No, the only change is to fix ACPI to defer parsing the information. I'm not changing every user of it. Also, we already have several other drivers (PCI bus for example) that do a lot of work in bus_alloc_resource() already. ACPI is actually somewhat unique in that it wants to parse resources ahead of time rather than dynamically at bus_alloc_resource() anyways. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 10:54:13 2004 Return-Path: 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 C028316A4CE for ; Thu, 3 Jun 2004 10:54:13 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D9F043D5C for ; Thu, 3 Jun 2004 10:54:13 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 44024 invoked by uid 1000); 3 Jun 2004 17:54:14 -0000 Date: Thu, 3 Jun 2004 10:54:14 -0700 (PDT) From: Nate Lawson To: John Baldwin In-Reply-To: <200406030917.36901.jhb@FreeBSD.org> Message-ID: <20040603104616.I43856@root.org> References: <20040601141424.I29932@root.org> <200406021358.17521.jhb@FreeBSD.org> <20040602160338.T38138@root.org> <200406030917.36901.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 17:54:13 -0000 On Thu, 3 Jun 2004, John Baldwin wrote: > On Wednesday 02 June 2004 07:27 pm, Nate Lawson wrote: > > On Wed, 2 Jun 2004, John Baldwin wrote: > > > Ok, summary of PITAs after an hour or so of looking into it: > > > > I appreciate your efforts. Just to recap, we're trying to work around an > > API design problem with bus_config_intr(). > > Well, it depends. See, using the existing API, I can make it work now with a > small change. Here's some more food for thought. Specifically we are > dealing with properties of an IRQ resource, correct? Now, the flags in > struct resource now are provided by the driver as part of the request (align > to this many bytes, I want it to be prefetchable, etc.). The properties of > the actual hardware interrupt line are _not_ provided by the driver, but by > the firmware. Now, what's another attribute about an IRQ resource that is > provided by the firmware/BIOS. PCI interrupt routing! Yes, and where do we > go ask the firmware for that information? bus_alloc_resource! So, we have a > working model now. Except we already have the special bus_setup_intr() and bus_config_intr() methods in addition to bus_alloc_resource() and bus_activate_resource(). This indicates that a more general method is needed (bus_config_resource?) between alloc/activate to set any special options, properties, etc. It could just have a (void *) argument that is interpreted by the bus method in any way it wants. This could also allow someone to reconfigure resources by deactivating them, configuring them, then reactivating them. > > Just because bus_config_intr doesn't have a counterpart for storing the > > config doesn't mean the right thing to do is to force every user of it to > > re-parse/fetch the settings they already set. I understand this is a pain > > but the time to contain the damage is now rather than letting it spread > > more. > > No, the only change is to fix ACPI to defer parsing the information. I'm not > changing every user of it. Also, we already have several other drivers (PCI > bus for example) that do a lot of work in bus_alloc_resource() already. ACPI > is actually somewhat unique in that it wants to parse resources ahead of time > rather than dynamically at bus_alloc_resource() anyways. With hotplug, we're going to need ways for a separate routine to set resource attributes before bus_alloc_resource() time. Plus, you yourself are an advocate of a multi-pass probing approach that includes separating resource reservation from allocation. Regarding your workaround, I've sent you comments in private email and when we work them out, I'm ok with your patch going in. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 11:15:06 2004 Return-Path: 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 8893E16A4CE; Thu, 3 Jun 2004 11:15:06 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 278E243D31; Thu, 3 Jun 2004 11:15:06 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i53IBd5a047889; Thu, 3 Jun 2004 12:11:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Jun 2004 12:11:43 -0600 (MDT) Message-Id: <20040603.121143.08320551.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040603104616.I43856@root.org> References: <20040602160338.T38138@root.org> <200406030917.36901.jhb@FreeBSD.org> <20040603104616.I43856@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 18:15:06 -0000 In message: <20040603104616.I43856@root.org> Nate Lawson writes: : With hotplug, we're going to need ways for a separate routine to set : resource attributes before bus_alloc_resource() time. Plus, you yourself : are an advocate of a multi-pass probing approach that includes separating : resource reservation from allocation. I don't understand this comment at all. We already support two different hot-plug technologies that allocate resources out of memory, i/o and irq space. This is done by the bus that knows what resources the child needs before adding the child to the bus. Warner From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 13:36:07 2004 Return-Path: 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 8AF9216A4CE for ; Thu, 3 Jun 2004 13:36:07 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2988A43D39 for ; Thu, 3 Jun 2004 13:36:07 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 44764 invoked by uid 1000); 3 Jun 2004 20:36:08 -0000 Date: Thu, 3 Jun 2004 13:36:08 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040603.121143.08320551.imp@bsdimp.com> Message-ID: <20040603133254.N44646@root.org> References: <20040602160338.T38138@root.org> <200406030917.36901.jhb@FreeBSD.org> <20040603.121143.08320551.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 20:36:07 -0000 On Thu, 3 Jun 2004, M. Warner Losh wrote: > In message: <20040603104616.I43856@root.org> > Nate Lawson writes: > : With hotplug, we're going to need ways for a separate routine to set > : resource attributes before bus_alloc_resource() time. Plus, you yourself > : are an advocate of a multi-pass probing approach that includes separating > : resource reservation from allocation. > > I don't understand this comment at all. We already support two > different hot-plug technologies that allocate resources out of memory, > i/o and irq space. This is done by the bus that knows what resources > the child needs before adding the child to the bus. I don't have an example handy, but there are tables (SSDT) that can appear/disappear with device insertion and it would be helpful to be able to set up any resources described by them before device_attach() and alloc time. I'm interested why bus_{get,set}_resource even exist if our plan all along was to defer all resource parsing to alloc time. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 13:55:07 2004 Return-Path: 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 76CB916A4CE; Thu, 3 Jun 2004 13:55:07 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1698F43D39; Thu, 3 Jun 2004 13:55:07 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i53KqQRs049848; Thu, 3 Jun 2004 14:52:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Jun 2004 14:52:30 -0600 (MDT) Message-Id: <20040603.145230.13772293.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <20040603133254.N44646@root.org> References: <20040603104616.I43856@root.org> <20040603.121143.08320551.imp@bsdimp.com> <20040603133254.N44646@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@FreeBSD.ORG cc: jhb@FreeBSD.ORG Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 20:55:07 -0000 In message: <20040603133254.N44646@root.org> Nate Lawson writes: : On Thu, 3 Jun 2004, M. Warner Losh wrote: : > In message: <20040603104616.I43856@root.org> : > Nate Lawson writes: : > : With hotplug, we're going to need ways for a separate routine to set : > : resource attributes before bus_alloc_resource() time. Plus, you yourself : > : are an advocate of a multi-pass probing approach that includes separating : > : resource reservation from allocation. : > : > I don't understand this comment at all. We already support two : > different hot-plug technologies that allocate resources out of memory, : > i/o and irq space. This is done by the bus that knows what resources : > the child needs before adding the child to the bus. : : I don't have an example handy, but there are tables (SSDT) that can : appear/disappear with device insertion and it would be helpful to be able : to set up any resources described by them before device_attach() and alloc : time. I'm interested why bus_{get,set}_resource even exist if our plan : all along was to defer all resource parsing to alloc time. We already do that for pccard and cardbus. We parse the CIS or frob the BARs and allocate resources as appropriate. Hot swap pci bridges could do logically identical things when it detects a new device has appeared. Since there has to be some agent that adds the children, that agent also is responsible for dealing with the resources that the new, shiny device requires. Warner From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 3 23:05:00 2004 Return-Path: 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 25FAF16A4CE for ; Thu, 3 Jun 2004 23:04:59 -0700 (PDT) Received: from hellhound.ceribus.net (c-24-21-92-61.client.comcast.net [24.21.92.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9816343D1F for ; Thu, 3 Jun 2004 23:04:59 -0700 (PDT) (envelope-from grover@ceribus.net) Received: (qmail 65410 invoked by uid 1003); 4 Jun 2004 06:04:57 -0000 Received: from grover@ceribus.net by hellhound.ceribus.net by uid 89 with qmail-scanner-1.22 (clamscan: 0.70. spamassassin: 2.63. Clear:RC:1(192.168.200.200):. Processed in 0.964929 secs); 04 Jun 2004 06:04:57 -0000 Received: from unknown (HELO purgatory) (192.168.200.200) by 192.168.200.225 with SMTP; 4 Jun 2004 06:04:55 -0000 From: "Grover Lines" To: Date: Thu, 3 Jun 2004 23:04:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRJ+dvYBTyvjaN1QQKTuViYTSwLjA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Qmail-Scanner-Message-ID: <108632909667265404@hellhound.ceribus.net> Message-Id: <20040604060459.9816343D1F@mx1.FreeBSD.org> Subject: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 06:05:00 -0000 I've been building world on a daily basis and starting May 16 my kernel was hanging with ACPI enabled. Anyway since a couple days ago the system boots fine but hangs on reboot. My system is a K7S5A and here's my debugging info so that maybe it will help someone to fix the issue. boot -v with ACPI enabled http://www.ceribus.net/freebsd/dmesg.txt boot -v with ACPI disabled http://www.ceribus.net/freebsd/dmesg-wo.txt ASL http://www.ceribus.net/freebsd/grover-k7s5a.asl hellhound# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 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.disable_on_poweroff: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_history: 7673/0 If I set hw.acpi.disable_on_poweroff=1 I get a irq storm with the following output. Waiting (max 60 seconds) for system process vnlru' to stop...stopped Waiting (max 60 seconds) for system process bufdaemon' to stop... Interupt storm detected on "irq9: acpi0"; throttling interupt source stopped Waiting (max 60 seconds) for system process syncer' to stop...stopped Synching disks, buffers remaining... 20 20 9 9 Done Uptime: 6m9s Hangs....... Any help is appreciated From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 4 06:45:23 2004 Return-Path: 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 E290C16A4CE for ; Fri, 4 Jun 2004 06:45:22 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id C39F743D2D for ; Fri, 4 Jun 2004 06:45:22 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30445 invoked from network); 4 Jun 2004 13:45:13 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Jun 2004 13:45:12 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i54Dj9QN081001; Fri, 4 Jun 2004 09:45:09 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Fri, 4 Jun 2004 09:45:56 -0400 User-Agent: KMail/1.6 References: <20040601141424.I29932@root.org> <200406030917.36901.jhb@FreeBSD.org> <20040603104616.I43856@root.org> In-Reply-To: <20040603104616.I43856@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406040945.56645.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 13:45:23 -0000 On Thursday 03 June 2004 01:54 pm, Nate Lawson wrote: > On Thu, 3 Jun 2004, John Baldwin wrote: > > On Wednesday 02 June 2004 07:27 pm, Nate Lawson wrote: > > > On Wed, 2 Jun 2004, John Baldwin wrote: > > > > Ok, summary of PITAs after an hour or so of looking into it: > > > > > > I appreciate your efforts. Just to recap, we're trying to work around > > > an API design problem with bus_config_intr(). > > > > Well, it depends. See, using the existing API, I can make it work now > > with a small change. Here's some more food for thought. Specifically we > > are dealing with properties of an IRQ resource, correct? Now, the flags > > in struct resource now are provided by the driver as part of the request > > (align to this many bytes, I want it to be prefetchable, etc.). The > > properties of the actual hardware interrupt line are _not_ provided by > > the driver, but by the firmware. Now, what's another attribute about an > > IRQ resource that is provided by the firmware/BIOS. PCI interrupt > > routing! Yes, and where do we go ask the firmware for that information? > > bus_alloc_resource! So, we have a working model now. > > Except we already have the special bus_setup_intr() and bus_config_intr() > methods in addition to bus_alloc_resource() and bus_activate_resource(). > This indicates that a more general method is needed (bus_config_resource?) > between alloc/activate to set any special options, properties, etc. It > could just have a (void *) argument that is interpreted by the bus method > in any way it wants. This could also allow someone to reconfigure > resources by deactivating them, configuring them, then reactivating them. Yes, whatever model we go with, setup_intr/teardown_intr() need to die. I think that the nexus drivers should setup interrupt handlers when an IRQ resource is activated (done automatically during a RF_ACTIVE bus_alloc_resource()). It seems we have a few different types of meta-data associated with a resource: 1) Data that the device driver provides (for example, alignment of memory, whether or not memory is prefetchable, interrupt routine and argument) 2) Data that the firmware provides (PCI interrupt routing, interrupt properties (trigger/polarity). The bus driver provides this. Right now our current model is to use flags to bus_alloc_resource() for 1) with a hack for interrupt handler variables and to do 2) during bus_alloc_resource()'s implementation. If a bus wants to cache data for 2) earlier than bus_alloc_resource(), it can either provide its own method of doing this (this is what my patch does for ACPI by using _CRS as the cache) or we can try to push the data down into the resource list. We need a better solution for 1) though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 4 08:28:03 2004 Return-Path: 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 292C616A4CE for ; Fri, 4 Jun 2004 08:28:03 -0700 (PDT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DC743D54 for ; Fri, 4 Jun 2004 08:28:02 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Fri, 04 Jun 2004 08:28:01 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6CF675D09; Fri, 4 Jun 2004 08:28:01 -0700 (PDT) To: "Grover Lines" In-reply-to: Your message of "Thu, 03 Jun 2004 23:04:55 PDT." <20040604060459.9816343D1F@mx1.FreeBSD.org> Date: Fri, 04 Jun 2004 08:28:01 -0700 From: "Kevin Oberman" Message-Id: <20040604152801.6CF675D09@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 15:28:03 -0000 > From: "Grover Lines" > Date: Thu, 3 Jun 2004 23:04:55 -0700 > Sender: owner-freebsd-acpi@freebsd.org > > I've been building world on a daily basis and starting May 16 my kernel was > hanging with ACPI enabled. Anyway since a couple days ago the system boots > fine but hangs on reboot. My system is a K7S5A and here's my debugging info > so that maybe it will help someone to fix the issue. > > boot -v with ACPI enabled http://www.ceribus.net/freebsd/dmesg.txt > boot -v with ACPI disabled http://www.ceribus.net/freebsd/dmesg-wo.txt > > ASL http://www.ceribus.net/freebsd/grover-k7s5a.asl > > hellhound# sysctl hw.acpi > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > 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.disable_on_poweroff: 0 > hw.acpi.reset_video: 1 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_history: 7673/0 > > > If I set hw.acpi.disable_on_poweroff=1 I get a irq storm with the following > output. > > Waiting (max 60 seconds) for system process vnlru' to stop...stopped Waiting > (max 60 seconds) for system process bufdaemon' to stop... Interupt storm > detected on "irq9: acpi0"; throttling interupt source stopped Waiting (max > 60 seconds) for system process syncer' to stop...stopped > > Synching disks, buffers remaining... 20 20 9 9 Done > Uptime: 6m9s > > Hangs....... > > Any help is appreciated The interrupt storm you are seeing is well known and should be gone with current. It was never a real problem, just annoying messages. The hang is unrelated. Back out /sys/i386/i386/intr_machdep.c V1.6. It involves moving two lines of code. That will cure the hang. Combine that with an updated kernel and the messages should be gone, too. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 4 08:50:39 2004 Return-Path: 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 46DEE16A4CE for ; Fri, 4 Jun 2004 08:50:39 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A0D643D48 for ; Fri, 4 Jun 2004 08:50:39 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 04 Jun 2004 08:50:23 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1A82D5D08; Fri, 4 Jun 2004 08:50:23 -0700 (PDT) To: "Grover Lines" In-reply-to: Your message of "Fri, 04 Jun 2004 08:28:01 PDT." <20040604152801.6CF675D09@ptavv.es.net> Date: Fri, 04 Jun 2004 08:50:23 -0700 From: "Kevin Oberman" Message-Id: <20040604155023.1A82D5D08@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 15:50:39 -0000 Following up my own post, I see that jhb has posted a one line fix to current that fixes the real problem that was previously masked by the error in intr_machdep.c. So leave /sys/i386/i386/intr_machdep.c alone and remove the line: while (cpu_idle_busy > 0) at about line 379 of /sys/dev/acpica/acpi_cpu.c. (Or, better yet, see and apply the patch posted to current.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 00:09:17 2004 Return-Path: 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 0822716A4CE for ; Sat, 5 Jun 2004 00:09:17 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2F59843D1D for ; Sat, 5 Jun 2004 00:09:15 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 54920 invoked by uid 1000); 5 Jun 2004 07:08:26 -0000 Date: Sat, 5 Jun 2004 00:08:26 -0700 (PDT) From: Nate Lawson To: current@freebsd.org Message-ID: <20040605000546.O54841@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: cvs commit: src/sys/dev/acpica acpi_cpu.c src/share/man/man4 acpi.4 (fwd) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 07:09:17 -0000 Reboots should continue to work and Cx idling should work the same. Please test. This patch finishes the job of not being affected by interrupt preemption. Thanks to jhb@ for tracking down the original problem. -Nate ---------- Forwarded message ---------- njl 2004/06/05 07:02:18 GMT FreeBSD src repository Modified files: sys/dev/acpica acpi_cpu.c share/man/man4 acpi.4 Log: Rework acpi_cpu_idle() to select the next idle state before sleeping, not after. Unify the paths for all Cx states. Remove cpu_idle_busy and instead do the little profiling we need before re-enabling interrupts. Use 1 quantum as estimate for C1 sleep duration since the timer interrupt is the main reason we wake. While here, change the cx_history sysctl to cx_usage and report statistics for which idle states were used in terms of percent. This seems more intuitive than counters. Remove the cx_stats structure since it's no longer used. Update the man page. Change various types which do not need explicit size. Revision Changes Path 1.35 +4 -5 src/share/man/man4/acpi.4 1.39 +79 -110 src/sys/dev/acpica/acpi_cpu.c From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 00:28:53 2004 Return-Path: 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 4183816A4CE for ; Sat, 5 Jun 2004 00:28:53 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2DFF043D1D for ; Sat, 5 Jun 2004 00:28:53 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 55063 invoked by uid 1000); 5 Jun 2004 07:28:35 -0000 Date: Sat, 5 Jun 2004 00:28:35 -0700 (PDT) From: Nate Lawson To: Kevin Oberman In-Reply-To: <20040604155023.1A82D5D08@ptavv.es.net> Message-ID: <20040605002810.V55038@root.org> References: <20040604155023.1A82D5D08@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 07:28:53 -0000 On Fri, 4 Jun 2004, Kevin Oberman wrote: > Following up my own post, I see that jhb has posted a one line fix to > current that fixes the real problem that was previously masked by the > error in intr_machdep.c. > > So leave /sys/i386/i386/intr_machdep.c alone and remove the line: > while (cpu_idle_busy > 0) > at about line 379 of /sys/dev/acpica/acpi_cpu.c. (Or, better yet, see > and apply the patch posted to current.) This should be fixed now so cvsup and test. -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 04:01:46 2004 Return-Path: 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 EA5C416A4CE for ; Sat, 5 Jun 2004 04:01:46 -0700 (PDT) Received: from cusco.plum.be (213.219.184.220.adslpower.by.edpnet.be [213.219.184.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F6D43D1D for ; Sat, 5 Jun 2004 04:01:45 -0700 (PDT) (envelope-from marc.plumet@edpnet.be) Received: from edpnet.be (localhost.plum.be [127.0.0.1]) by cusco.plum.be (8.12.10/8.12.10) with ESMTP id i64B6uLj000987 for ; Sun, 4 Jul 2004 13:06:57 +0200 (CEST) (envelope-from marc.plumet@edpnet.be) Message-ID: <40E7E4D0.9@edpnet.be> From: Marc Plumet User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6a) Gecko/20031207 X-Accept-Language: en-us, en To: freebsd-acpi@FreeBSD.org Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: no floppy when acpi enabled. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 05 Jun 2004 11:01:47 -0000 X-Original-Date: Sun, 04 Jul 2004 13:06:56 +0200 X-List-Received-Date: Sat, 05 Jun 2004 11:01:47 -0000 Dear, I updated my BIOS, as recommended, but it did not solve my problem : When acpi enabled, my floppy is not present. When acpi disabled, the floppy is present. Here follow the answers to your questions. * Description of the buggy behavior, including system type and model and anything that causes the bug to appear. Also, please note as accurately as possible when the bug began occurring if it is new for you. When acpi enabled, my floppy is not present. When acpi disabled, the floppy is present. Motherboard : ASROCK GPRO, latest BIOS available is present : G PRO V1.4 (2003/04/14). Intel PIV - 1700 MHz. * The dmesg output after ``boot -v'', including any error messages generated by you exercising the bug. dmesg | grep fd : fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cmd 3 failed at out byte 1 of 3 fdc0: cannot reserve I/O port range (6 ports) * dmesg output from ``boot -v'' with ACPI disabled, if disabling it helps fix the problem. problem is fixed, dmesg is correct. * Output from ``sysctl hw.acpi''. This is also a good way of figuring out what features your system offers. hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 5 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_poweroff: 1 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 139604/0 * URL where your ACPI Source Language (ASL) can be found. Do not send the ASL directly to the list as it can be very large. Generate a copy of your ASL by running this command: http://www.plum.be/root-asrockGPro.asl (no error during compile iasl) I hope I gave all the necessary information. I love! Freebsd. Thanks a lot for your help ir. Marc Plumet. Belgium. +32 484 529 154 From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 08:36:30 2004 Return-Path: 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 0342316A4CE for ; Sat, 5 Jun 2004 08:36:30 -0700 (PDT) Received: from smtp-out1.xs4all.nl (smtp-out1.xs4all.nl [194.109.24.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EF7F43D48 for ; Sat, 5 Jun 2004 08:36:29 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-out1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i55FaHYU046045; Sat, 5 Jun 2004 17:36:17 +0200 (CEST) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i55FZSVx039128; Sat, 5 Jun 2004 17:35:28 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i55FZSnJ039127; Sat, 5 Jun 2004 17:35:28 +0200 (CEST) (envelope-from wkb) Date: Sat, 5 Jun 2004 17:35:28 +0200 From: Wilko Bulte To: Nate Lawson Message-ID: <20040605153528.GA39099@freebie.xs4all.nl> References: <20040604155023.1A82D5D08@ptavv.es.net> <20040605002810.V55038@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040605002810.V55038@root.org> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 15:36:30 -0000 On Sat, Jun 05, 2004 at 12:28:35AM -0700, Nate Lawson wrote: > On Fri, 4 Jun 2004, Kevin Oberman wrote: > > Following up my own post, I see that jhb has posted a one line fix to > > current that fixes the real problem that was previously masked by the > > error in intr_machdep.c. > > > > So leave /sys/i386/i386/intr_machdep.c alone and remove the line: > > while (cpu_idle_busy > 0) > > at about line 379 of /sys/dev/acpica/acpi_cpu.c. (Or, better yet, see > > and apply the patch posted to current.) > > This should be fixed now so cvsup and test. shutdown -p now again works as expected on my Compaq EVO N160 laptop. But the interrupt storm I still have: dc0: cmd 3 failed at out byte 1 of 3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1065764900 Hz quality 800 Timecounters tick every 10.000 msec Interrupt storm detected on "irq5: fwohci0 fxp0"; throttling interrupt source ad0: 19077MB [38760/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 wi0: at port 0x3080-0x30bf irq 10 function 0 confi g 1 on pccard0 wi0: [GIANT-LOCKED] That interrupt storm stuff goes away my using a modified aml that some kind soul posted for the N160 some months ago. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 09:04:52 2004 Return-Path: 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 A4BF916A4CE for ; Sat, 5 Jun 2004 09:04:52 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7670A43D39 for ; Sat, 5 Jun 2004 09:04:52 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 59788 invoked by uid 1000); 5 Jun 2004 16:04:53 -0000 Date: Sat, 5 Jun 2004 09:04:52 -0700 (PDT) From: Nate Lawson To: Wilko Bulte In-Reply-To: <20040605153528.GA39099@freebie.xs4all.nl> Message-ID: <20040605090353.L59777@root.org> References: <20040604155023.1A82D5D08@ptavv.es.net> <20040605002810.V55038@root.org> <20040605153528.GA39099@freebie.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: ACPI Interupt storm detected X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 16:04:52 -0000 On Sat, 5 Jun 2004, Wilko Bulte wrote: > On Sat, Jun 05, 2004 at 12:28:35AM -0700, Nate Lawson wrote: > > On Fri, 4 Jun 2004, Kevin Oberman wrote: > > > Following up my own post, I see that jhb has posted a one line fix to > > > current that fixes the real problem that was previously masked by the > > > error in intr_machdep.c. > > > > > > So leave /sys/i386/i386/intr_machdep.c alone and remove the line: > > > while (cpu_idle_busy > 0) > > > at about line 379 of /sys/dev/acpica/acpi_cpu.c. (Or, better yet, see > > > and apply the patch posted to current.) > > > > This should be fixed now so cvsup and test. > > shutdown -p now again works as expected on my Compaq EVO N160 laptop. > > But the interrupt storm I still have: > > dc0: cmd 3 failed at out byte 1 of 3 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 1065764900 Hz quality 800 > Timecounters tick every 10.000 msec > Interrupt storm detected on "irq5: fwohci0 fxp0"; throttling interrupt > source > ad0: 19077MB [38760/16/63] at ata0-master UDMA100 > acd0: CDROM at ata1-master PIO4 > wi0: at port 0x3080-0x30bf irq 10 function 0 > confi > g 1 on pccard0 > wi0: [GIANT-LOCKED] > > That interrupt storm stuff goes away my using a modified aml > that some kind soul posted for the N160 some months ago. I'd like to see the patch. It's going to be a problem with your _PRT or other irq object, not GPEs like what I committed. GPEs are used for device wake, lid, and button switches typically. -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 09:15:00 2004 Return-Path: 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 BF3E516A4CE for ; Sat, 5 Jun 2004 09:15:00 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id A7F4E43D2F for ; Sat, 5 Jun 2004 09:15:00 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 59849 invoked by uid 1000); 5 Jun 2004 16:14:45 -0000 Date: Sat, 5 Jun 2004 09:14:45 -0700 (PDT) From: Nate Lawson To: Marc Plumet In-Reply-To: <40E7E4D0.9@edpnet.be> Message-ID: <20040605090930.U59777@root.org> References: <40E7E4D0.9@edpnet.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@FreeBSD.org Subject: Re: no floppy when acpi enabled. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 16:15:00 -0000 Thank you for quite possibly the best bug report ever. :) It's good to see someone read the handbook. On Sun, 4 Jul 2004, Marc Plumet wrote: > When acpi enabled, my floppy is not present. > When acpi disabled, the floppy is present. > Motherboard : ASROCK GPRO, latest BIOS available is present : G PRO > V1.4 (2003/04/14). > Intel PIV - 1700 MHz. > > * The dmesg output after ``boot -v'', including any error messages > generated by you exercising the bug. > > dmesg | grep fd : > fdc0: cmd 3 failed at out byte 1 of 3 > fdc0: cmd 3 failed at out byte 1 of 3 > fdc0: cannot reserve I/O port range (6 ports) > > * Output from ``sysctl hw.acpi''. This is also a good way of > figuring out what features your system offers. > > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: S1 > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 5 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_poweroff: 1 > hw.acpi.reset_video: 1 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 139604/0 Hmm, this looks like you're not running -current. Is this 5.2-RELEASE? Could you do a test boot with a recent 5-current snapshot (see snapshots.jp.freebsd.org if you need an iso). The boot-only kernel would be fine. > * URL where your ACPI Source Language (ASL) can be found. Do not > send the ASL directly to the list as it can be very large. > Generate a copy of your ASL by running this command: > > http://www.plum.be/root-asrockGPro.asl > (no error during compile iasl) Thanks. Nothing particularly wrong here with the resources except they appear to be split. Please send me (private mail) the output of "devinfo -r" after booting both with and without ACPI. > I hope I gave all the necessary information. > I love! Freebsd. We do too! -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 09:18:04 2004 Return-Path: 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 A206516A4CE for ; Sat, 5 Jun 2004 09:18:04 -0700 (PDT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC7E43D1D for ; Sat, 5 Jun 2004 09:18:04 -0700 (PDT) (envelope-from plexus@snafu.de) Received: from pd9eb1df1.dip.t-dialin.net ([217.235.29.241] helo=snafu.de) by smart.eusc.inter.net with asmtp (Exim 3.36 #4) id 1BWdrc-00068A-00 for acpi@freebsd.org; Sat, 05 Jun 2004 18:17:44 +0200 Message-ID: <40C1F228.8060401@snafu.de> Date: Sat, 05 Jun 2004 18:17:44 +0200 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 16:18:04 -0000 Hello, With todays CURRENT, resuming from S3 results in a black screen on my Thinkpad R51. Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 13:20:22 2004 Return-Path: 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 1F9B016A4CE for ; Sat, 5 Jun 2004 13:20:22 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0756743D3F for ; Sat, 5 Jun 2004 13:20:22 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 61023 invoked by uid 1000); 5 Jun 2004 20:20:23 -0000 Date: Sat, 5 Jun 2004 13:20:22 -0700 (PDT) From: Nate Lawson To: "Oliver B. Fischer" In-Reply-To: <40C1F228.8060401@snafu.de> Message-ID: <20040605132007.R60990@root.org> References: <40C1F228.8060401@snafu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 20:20:22 -0000 On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > With todays CURRENT, resuming from S3 results in a black screen on my > Thinkpad R51. Were you running with special patches before (i.e. DPMS)? -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 13:34:47 2004 Return-Path: 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 F08D516A4CE for ; Sat, 5 Jun 2004 13:34:47 -0700 (PDT) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CE043D2D for ; Sat, 5 Jun 2004 13:34:47 -0700 (PDT) (envelope-from plexus@snafu.de) Received: from pd951746d.dip.t-dialin.net ([217.81.116.109] helo=snafu.de) by smart.eusc.inter.net with asmtp (Exim 3.36 #4) id 1BWhsM-00077j-00; Sat, 05 Jun 2004 22:34:47 +0200 Message-ID: <40C22E67.5090008@snafu.de> Date: Sat, 05 Jun 2004 22:34:47 +0200 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <40C1F228.8060401@snafu.de> <20040605132007.R60990@root.org> In-Reply-To: <20040605132007.R60990@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 20:34:48 -0000 Nate Lawson wrote: > On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > >>With todays CURRENT, resuming from S3 results in a black screen on my >>Thinkpad R51. > > > Were you running with special patches before (i.e. DPMS)? No, I didn't. I used a normal CVS checkout. BTW, I still have this checkout in a separat directory. Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 14:42:56 2004 Return-Path: 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 971A316A4CE for ; Sat, 5 Jun 2004 14:42:56 -0700 (PDT) Received: from havoc.eusc.inter.net (havoc.eusc.inter.net [213.73.101.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60EEC43D2D for ; Sat, 5 Jun 2004 14:42:56 -0700 (PDT) (envelope-from plexus@snafu.de) Received: from pd9e0ee6e.dip.t-dialin.net ([217.224.238.110] helo=snafu.de) by havoc.eusc.inter.net with asmtp (Exim 3.36 #3) id 1BWiwJ-0003Q5-00; Sat, 05 Jun 2004 23:42:55 +0200 Message-ID: <40C23E60.7010503@snafu.de> Date: Sat, 05 Jun 2004 23:42:56 +0200 From: "Oliver B. Fischer" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <40C1F228.8060401@snafu.de> <20040605132007.R60990@root.org> In-Reply-To: <20040605132007.R60990@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 21:42:56 -0000 Nate Lawson wrote: > On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > >>With todays CURRENT, resuming from S3 results in a black screen on my >>Thinkpad R51. > > > Were you running with special patches before (i.e. DPMS)? Sorry I have fogotton to say, that it happens only if I boot in safe mode. Regards, Oliver Fischer From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 19:44:47 2004 Return-Path: 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 4B4A916A4CE for ; Sat, 5 Jun 2004 19:44:47 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E7D443D1F for ; Sat, 5 Jun 2004 19:44:47 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 62648 invoked by uid 1000); 6 Jun 2004 02:44:29 -0000 Date: Sat, 5 Jun 2004 19:44:29 -0700 (PDT) From: Nate Lawson To: "Oliver B. Fischer" In-Reply-To: <40C23E60.7010503@snafu.de> Message-ID: <20040605194248.W62622@root.org> References: <40C1F228.8060401@snafu.de> <20040605132007.R60990@root.org> <40C23E60.7010503@snafu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 02:44:47 -0000 On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > Nate Lawson wrote: > > On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > > > >>With todays CURRENT, resuming from S3 results in a black screen on my > >>Thinkpad R51. > > > > Were you running with special patches before (i.e. DPMS)? > > Sorry I have fogotton to say, that it happens only if I boot in safe mode. Um, safe mode disables ACPI so how can you suspend/resume in safe mode? -Nate Here are all the things safe mode disables: dup bootsafekey @ = if s" arch-i386" environment? if s" acpi_load" unsetenv s" 1" s" hint.acpi.0.disabled" setenv s" 1" s" loader.acpi_disabled_by_user" setenv s" 1" s" hint.apic.0.disabled" setenv then s" 0" s" hw.ata.ata_dma" setenv s" 0" s" hw.ata.atapi_dma" setenv s" 0" s" hw.ata.wc" setenv s" 0" s" hw.eisa_slots" setenv 0 boot From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 5 19:45:06 2004 Return-Path: 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 7ECFE16A4CE for ; Sat, 5 Jun 2004 19:45:06 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 6CD3643D2D for ; Sat, 5 Jun 2004 19:45:06 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 62653 invoked by uid 1000); 6 Jun 2004 02:44:53 -0000 Date: Sat, 5 Jun 2004 19:44:53 -0700 (PDT) From: Nate Lawson To: "Oliver B. Fischer" In-Reply-To: <40C22E67.5090008@snafu.de> Message-ID: <20040605194435.G62622@root.org> References: <40C1F228.8060401@snafu.de> <20040605132007.R60990@root.org> <40C22E67.5090008@snafu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: Screen stays black after resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 02:45:06 -0000 On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > Nate Lawson wrote: > > On Sat, 5 Jun 2004, Oliver B. Fischer wrote: > > > >>With todays CURRENT, resuming from S3 results in a black screen on my > >>Thinkpad R51. > > > > > > Were you running with special patches before (i.e. DPMS)? > > No, I didn't. I used a normal CVS checkout. BTW, I still have this > checkout in a separat directory. What are the dates between the two versions (working and not)? -Nate