From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 15 03:09:41 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 779CD16A4CE for ; Sun, 15 Aug 2004 03:09:41 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2053443D1D for ; Sun, 15 Aug 2004 03:09:41 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7F37V8U000861; Sat, 14 Aug 2004 20:07:34 -0700 Message-ID: <411ED36A.6070307@root.org> Date: Sat, 14 Aug 2004 20:07:22 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iain.templeton@cisra.canon.com.au References: <20030604085348.A4BE398E7E@blow.research.canon.com.au> In-Reply-To: <20030604085348.A4BE398E7E@blow.research.canon.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: [acpi-jp 2311] ACPI and PCI vs interrupt routing on Sony VAIO's 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, 15 Aug 2004 03:09:41 -0000 Iain Templeton wrote: > Hi, > > I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this > problem was previous posted elsewhere as "Weird as* sound problem"). This problem > has been confirmed on at least one other Sony VAIO model (I forget which). > > They're both Intel i830M chipset based. > > Basically, the LNKB interrupt configuration register is not being initialised, > so the interrupt never gets routed, and so the interrupt never gets to the CPU. > Result: Sound doesn't work. > > A really hacky solution to this is to run the command: > pciconf -w -b pci0:31:0 0x61 9 Have you tried a recent -current? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 15 06:02:41 2004 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3521516A4CE; Sun, 15 Aug 2004 06:02:41 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 145DF43D2D; Sun, 15 Aug 2004 06:02:41 +0000 (GMT) (envelope-from njl@FreeBSD.org) Received: from freefall.freebsd.org (njl@localhost [127.0.0.1]) i7F62eW9024260; Sun, 15 Aug 2004 06:02:40 GMT (envelope-from njl@freefall.freebsd.org) Received: (from njl@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7F62ex4024256; Sun, 15 Aug 2004 06:02:40 GMT (envelope-from njl) Date: Sun, 15 Aug 2004 06:02:40 GMT From: Nate Lawson Message-Id: <200408150602.i7F62ex4024256@freefall.freebsd.org> To: bobhamm49@cox.net, njl@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: i386/67770: X11 kills system after upgrade to 5.2.1 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, 15 Aug 2004 06:02:41 -0000 Synopsis: X11 kills system after upgrade to 5.2.1 State-Changed-From-To: analyzed->closed State-Changed-By: njl State-Changed-When: Sun Aug 15 06:02:15 GMT 2004 State-Changed-Why: Submitter indicates problem is fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=67770 From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 15 06:10:28 2004 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7CCA16A4CE for ; Sun, 15 Aug 2004 06:10:28 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E0A43D39 for ; Sun, 15 Aug 2004 06:10:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i7F6AScC028181 for ; Sun, 15 Aug 2004 06:10:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7F6ASRY028180; Sun, 15 Aug 2004 06:10:28 GMT (envelope-from gnats) Date: Sun, 15 Aug 2004 06:10:28 GMT Message-Id: <200408150610.i7F6ASRY028180@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Nate Lawson Subject: Re: i386/67770 X11 problems with ACPI X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nate Lawson List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 06:10:28 -0000 The following reply was made to PR i386/67770; it has been noted by GNATS. From: Nate Lawson To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: i386/67770 X11 problems with ACPI Date: Sat, 14 Aug 2004 23:01:50 -0700 FYI, the submitter indicates the problem is gone. -------- Original Message -------- Subject: Re: i386/67770 X11 problems with ACPI Date: Sat, 14 Aug 2004 10:33:10 -0700 From: Robert Hamm To: Nate Lawson References: <411A51AE.4020805@root.org> Yes, it's fixed. Nate Lawson wrote: > Could you try a newer snapshot from snapshots.jp.freebsd.org and let > me know if the problem is still present? > > -Nate > From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 15 23:41: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 DC10E16A4CE; Sun, 15 Aug 2004 23:41:34 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B2CA43D2D; Sun, 15 Aug 2004 23:41:30 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7FNfM8U030148; Sun, 15 Aug 2004 16:41:23 -0700 Message-ID: <411FF4A2.20404@root.org> Date: Sun, 15 Aug 2004 16:41:22 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) 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: [Fwd: [src] cvs commit: src/usr.sbin/acpi/acpiconf acpiconf.c] 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, 15 Aug 2004 23:41:35 -0000 As discussed below, I plan to remove acpi_Enable and acpi_Disable and the associated ioctls before 5.3. The reasoning is that they cause problems for some people, are not very useful, and are not guaranteed by the std. Comments welcome. -------- Original Message -------- Subject: [src] cvs commit: src/usr.sbin/acpi/acpiconf acpiconf.c Date: Sun, 15 Aug 2004 23:39:40 +0000 (GMT) From: Nate Lawson To: njl@FreeBSD.ORG njl 2004-08-15 23:39:37 UTC FreeBSD src repository Modified files: usr.sbin/acpi/acpiconf acpiconf.c Log: Comment out the ability to enable/disable ACPI at runtime. This appears to not work reliably and crash some systems. It is not supported at all on others. Pending discussion, the underlying ioctls will be removed. Revision Changes Path 1.15 +4 -0 src/usr.sbin/acpi/acpiconf/acpiconf.c From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 00:54:11 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 2EAE516A4CE for ; Mon, 16 Aug 2004 00:54:11 +0000 (GMT) Received: from mail.iinet.net.au (mail-04.iinet.net.au [203.59.3.36]) by mx1.FreeBSD.org (Postfix) with SMTP id 9205143D1D for ; Mon, 16 Aug 2004 00:54:09 +0000 (GMT) (envelope-from jne@iinet.net.au) Received: (qmail 17003 invoked from network); 16 Aug 2004 00:54:07 -0000 Received: from unknown (HELO ?192.168.0.10?) (203.217.51.228) by mail.iinet.net.au with SMTP; 16 Aug 2004 00:54:06 -0000 Message-ID: <4120057A.9060304@iinet.net.au> Date: Mon, 16 Aug 2004 10:53:14 +1000 From: Michael McCormack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: AML and other troubles 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, 16 Aug 2004 00:54:11 -0000 Greetings all. I'm running into huge trouble trying to get my laptop up and running with FreeBSD. It is a Compaq armada e500. I know this model works under BSD; The FLCL says so :) However, mine seems to be somewhat broken. I get these errors at boot: ACPI-1287: *** Error: Method execution failed [\\_SB_.C005.C00B] (Node 0xc136b920), AE_AML_BUFFER_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.C005.C00F] (Node 0xc136b900), AE_AML_BUFFER_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.C005._CRS] (Node 0xc136b8e0), AE_AML_BUFFER_LIMIT ACPI-0226: *** Error: Return object type is incorrect [\\_SB_.C005._CRS] (Node 0xc136b8e0), AE_TYPE can't fetch resources for \\_SB_.C005 - AE_TYPE I dumped out my DSDT and had a look thru it. \_SB_.C005 seems to be a device with _HID "PNP0A03" (or as compaq prefers, "*PNP0A03" -- more on that later). AFAIK, PNP0A03 is a PCI root bridge. I'm thinking not being able to fetch resources for a root bridge is a Bad Thing. This also ties into the problems I'm having with the video card.. startx just hangs. xf86cfg hangs. xf86config runs, but the generated config file causes startx to hang no matter what I choose (even generic VGA). There's never any errors in the logfile, it just stops after (surprise!) the PCI probe stuff. The system is dual boot, freeBSD and win'98, since some of the settings and stuff can only be accessed from windows software. I have similar problems under 'doze.. The default memory address setting of the AGP bridge conflicts with just about everything on the system; With the default setting I can't get better than 640x480x8bit colour. However, If I manually override the memory address setting of the AGP bridge, i get 1024x768x24bit, happiness, puppies, etc. I consider myself a reasonably non-crap programmer, and I've already started debugging my DSDT AML; So far I've removed the "*" in front of all the device names, and inserted a couple "return(0)" statements so it compiles without errors (only warnings..) but I have no clue where to start when it comes to fixing the above errors. I'd be more than happy to do the hard work myself and post the diffs somewhere if somebody could just tell me what to look for :) I can post dmesg output, aml, logfiles or anything else people want if it will help. And yes, I've tried several different BIOS revisions. All give the same errors. I'm attempting to debug the most recent one. Thanks. -Michael. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 03:55: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 7C10616A4CE for ; Mon, 16 Aug 2004 03:55:55 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26CCA43D1F for ; Mon, 16 Aug 2004 03:55:55 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7G3tp8U002014; Sun, 15 Aug 2004 20:55:54 -0700 Message-ID: <41203047.5020708@root.org> Date: Sun, 15 Aug 2004 20:55:51 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael McCormack References: <4120057A.9060304@iinet.net.au> In-Reply-To: <4120057A.9060304@iinet.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: AML and other troubles 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, 16 Aug 2004 03:55:55 -0000 Michael McCormack wrote: > Greetings all. > > I'm running into huge trouble trying to get my laptop up and running > with FreeBSD. It is a Compaq armada e500. I know this model works under > BSD; The FLCL says so :) However, mine seems to be somewhat broken. > > I get these errors at boot: > > ACPI-1287: *** Error: Method execution failed [\\_SB_.C005.C00B] (Node > 0xc136b920), AE_AML_BUFFER_LIMIT > ACPI-1287: *** Error: Method execution failed [\\_SB_.C005.C00F] (Node > 0xc136b900), AE_AML_BUFFER_LIMIT > ACPI-1287: *** Error: Method execution failed [\\_SB_.C005._CRS] (Node > 0xc136b8e0), AE_AML_BUFFER_LIMIT > ACPI-0226: *** Error: Return object type is incorrect [\\_SB_.C005._CRS] > (Node 0xc136b8e0), AE_TYPE > can't fetch resources for \\_SB_.C005 - AE_TYPE What version of FreeBSD are you running? Handling of PNPIDs that have '*' was fixed at least a year ago. -Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 04:07: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 238CB16A4CE; Mon, 16 Aug 2004 04:07:53 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3BCE43D46; Mon, 16 Aug 2004 04:07:52 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7G47p8U002171; Sun, 15 Aug 2004 21:07:52 -0700 Message-ID: <41203316.90801@root.org> Date: Sun, 15 Aug 2004 21:07:50 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Riccardo Torrini References: <20040815223335.GA82743@trudy.torrini.home> In-Reply-To: <20040815223335.GA82743@trudy.torrini.home> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: Disabled known-bad BIOS revisions 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, 16 Aug 2004 04:07:53 -0000 Riccardo Torrini wrote: > As explained in UPDATING on 20040630, ACPI has been updated to disable > known-bad BIOS revisions. A message will be printed on the console... > > Machine is a dual pIII/500, MoBo is an ASUS P2B-DS (dual+scsi) > > Without hint.acpi.0.disabled="0" I got a "auto-reboot-without-panic" > after loading kernel (or after loading/skipping ACPI, it is too fast > so I can't see any message at all). Try booting with "unset acpi_load" so that acpi is not even loaded. Does your system work then? If so, the problem that needs to be fixed is booting with ACPI disabled and is a bug. I find it hard to believe that your system was designed to not work without ACPI since it is from 1999. > (only a "don't know if related" problem: after switching to sound and > snd_* my machine don't play any sound, device is found at boot but no > mixer nor dsp are created into /dev, I will send a separate message). > > Other test I have done between jul/aug: > - kernel without SMP, no hint: GOOD, see the disabled message > - kernel with SMP, hint to enable ACPI: GOOD, no message > - kernel with SMP, no hint: FAIL, AUTO-REBOOT > > Can I vote for "removing" this MoBo from quirks? What test can I do > to prove that is works? If you need an acpi dump you can found here: > ftp://ftp.torrini.org/pub/FreeBSD/trudy.acpidump-vt.gz > ftp://ftp.torrini.org/pub/FreeBSD/trudy.acpidump-vtd.gz > (first is acpidump -v -t, second is the same plus -d) No, the hints give the same behavior you'd have on Windows, namely that it wouldn't even install the ACPI version of the HAL. Note that with ACPI enabled your sound card doesn't work. This machine's BIOS was built in 1999. Linux doesn't even support ACPI for machines older than 2001. -Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 05:32:37 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 C3EEA16A4CE for ; Mon, 16 Aug 2004 05:32:37 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7912143D1D for ; Mon, 16 Aug 2004 05:32:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7G5Wa8U003198; Sun, 15 Aug 2004 22:32:36 -0700 Message-ID: <412046F4.6010704@root.org> Date: Sun, 15 Aug 2004 22:32:36 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael McCormack References: <4120057A.9060304@iinet.net.au> <41203047.5020708@root.org> <4120457B.1060807@iinet.net.au> In-Reply-To: <4120457B.1060807@iinet.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: AML and other troubles 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, 16 Aug 2004 05:32:37 -0000 Michael McCormack wrote: > Nate Lawson wrote: > >> What version of FreeBSD are you running? Handling of PNPIDs that have >> '*' was fixed at least a year ago. >> >> -Nate > > 5.2.1-release. > > Joke's on me I guess :) should have done more research.. I took out the > '*'s because iasl was complaining about them.. Try a recent -current or wait for 5.3-RC1. Either way, your problems should be fixed. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 11:02: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 4719716A4CE for ; Mon, 16 Aug 2004 11:02:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E3EF43D2F for ; Mon, 16 Aug 2004 11:02:56 +0000 (GMT) (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 i7GB2um4096748 for ; Mon, 16 Aug 2004 11:02:56 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7GB2sxc096724 for freebsd-acpi@freebsd.org; Mon, 16 Aug 2004 11:02:54 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 16 Aug 2004 11:02:54 GMT Message-Id: <200408161102.i7GB2sxc096724@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, 16 Aug 2004 11:02:56 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 1 problem 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 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/03/17] misc/64365 acpi ACPI problems o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) 2 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 12:15:44 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 862DD16A4D3; Mon, 16 Aug 2004 12:15:44 +0000 (GMT) Received: from av5-1-sn3.vrr.skanova.net (av5-1-sn3.vrr.skanova.net [81.228.9.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C90343D46; Mon, 16 Aug 2004 12:15:44 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 662BB37E7C; Mon, 16 Aug 2004 14:15:43 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 557E337E4A; Mon, 16 Aug 2004 14:15:43 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1567138007; Mon, 16 Aug 2004 14:15:43 +0200 (CEST) From: "Daniel Eriksson" To: "'Riccardo Torrini'" Date: Mon, 16 Aug 2004 14:15:46 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41203316.90801@root.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSDRywoCRzZnLLHRCyqmHffbMHucwAQ0uPQ cc: acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: RE: Disabled known-bad BIOS revisions 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, 16 Aug 2004 12:15:44 -0000 Try upgrading your BIOS to the latest beta version. I'm running a P2B-DS with ACPI enabled without any problems, using the 1014.003 bios available here: ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Slot_I/INTEL_Chipset/i440BX/P2B-DS/ /Daniel Eriksson From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 16:24:12 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 09FB016A4CE for ; Mon, 16 Aug 2004 16:24:12 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF53E43D41 for ; Mon, 16 Aug 2004 16:24:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7GGOFeP018142 for ; Mon, 16 Aug 2004 09:24:15 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7GGOFft018141 for freebsd-acpi@freebsd.org; Mon, 16 Aug 2004 09:24:15 -0700 Date: Mon, 16 Aug 2004 09:24:15 -0700 From: Brooks Davis To: freebsd-acpi@freebsd.org Message-ID: <20040816162415.GA16807@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: acpi_thermal consuming all CPU 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, 16 Aug 2004 16:24:12 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Some time between ~July 29 and August 15th, something changed that causes acpi_thermal is get stuck in the ecpoll state when my laptop is under load. The basic symptom is that I start a build and after a bit, system peformance gets lousy (the mouse moves ever few seconds, nothing updates, etc). When I managed to get top running on the console, I found that acpi_thermal was consuming >98% of the CPU and was constantly in the ecpoll state. The fans do not run and the system gets very hot (90C). Booting an old kernel or booting with acpi disabled seems to fix the problem. In case it's relevent, prior to Nate's fixes at Usenix, I couldn't reliably get termperature or power state out of acpi. The system is an HP Omnibook 500. I believe I'm running the latest BIOS. Here's the sysctl hw.acpi output: [9:14am] brooks@minya (~): sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5=20 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.reset_video: 1 hw.acpi.cpu.throttle_max: 8 hw.acpi.cpu.throttle_state: 8 hw.acpi.cpu.cx_supported: C1/0 C2/10 hw.acpi.cpu.cx_lowest: C2 hw.acpi.cpu.cx_usage: 0.01% 99.98% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 3202 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3582 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3782 hw.acpi.thermal.tz0._ACx: 3432 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.acline: 1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 3 hw.acpi.battery.info_expire: 5 The AML is here: http://people.freebsd.org/~brooks/debug/brooks-HPOmnibook500.asl -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBIN+vXY6L6fI4GtQRAlPAAJ94r3vDHn3QKCRkQReV62/BWKc7cACgwmk1 nIMO1jmLk2bCpcjtjCDzRP0= =oIN3 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 17:44: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 7ED4F16A4CE; Mon, 16 Aug 2004 17:44:21 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4861843D39; Mon, 16 Aug 2004 17:44:21 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7GHiC8U017186; Mon, 16 Aug 2004 10:44:13 -0700 Message-ID: <4120F26B.1040808@root.org> Date: Mon, 16 Aug 2004 10:44:11 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Farfeleder References: <411C6144.6060100@root.org> <20040814104054.GA579@wombat.fafoe.narf.at> In-Reply-To: <20040814104054.GA579@wombat.fafoe.narf.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: acpi mpsafe committed 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, 16 Aug 2004 17:44:21 -0000 Stefan Farfeleder wrote: > On Thu, Aug 12, 2004 at 11:35:48PM -0700, Nate Lawson wrote: > >>Let me know if there are any problems. > > > I'm now getting a panic if I want to suspend my Thinkpad R32 via Fn-F4 > (manually transcribed): > > panic: mutex Giant not owned at /usr/src/sys/net/if.c:1874 > > db> trace > kdb_enter > panic > _mtx_assert > if_start > ieee80211_mgmt_output > ieee80211_send_mgmt > ieee80211_newstate > wi_newstate > wi_stop > wi_pci_suspend > bus_generic_suspend > pci_suspend > bus_generic_suspend > bus_generic_suspend > pci_suspend > bus_generic_suspend > bus_generic_suspend > bus_generic_suspend > bus_generic_suspend > acpi_SetSleepState > acpi_system_eventhandler_sleep > acpi_event_sleep_button_sleep > acpi_button_notify_sleep > acpi_task_thread > fork_exit > fork_trampoline > > Dmesg is at http://people.freebsd.org/~stefanf/dmesg.2004-08-14_11:50 . > I'm happy to provide more information if anyone needs it. > > Thanks, > Stefan I can't see how the acpi commit affects this. The assertion is in the if code so it's likely that wi(4) is not setting the right flag to acquire Giant before if_start. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 18:35:36 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 73FC916A4CE; Mon, 16 Aug 2004 18:35:36 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2725443D55; Mon, 16 Aug 2004 18:35:36 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7GIXY81082167; Mon, 16 Aug 2004 14:33:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7GIXUad082164; Mon, 16 Aug 2004 14:33:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 16 Aug 2004 14:33:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nate Lawson In-Reply-To: <4120F26B.1040808@root.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Stefan Farfeleder cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: acpi mpsafe committed 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, 16 Aug 2004 18:35:36 -0000 On Mon, 16 Aug 2004, Nate Lawson wrote: > Stefan Farfeleder wrote: > > On Thu, Aug 12, 2004 at 11:35:48PM -0700, Nate Lawson wrote: > > > >>Let me know if there are any problems. > > > > > > I'm now getting a panic if I want to suspend my Thinkpad R32 via Fn-F4 > > (manually transcribed): > > > > panic: mutex Giant not owned at /usr/src/sys/net/if.c:1874 > > > > db> trace > > kdb_enter > > panic > > _mtx_assert > > if_start > > ieee80211_mgmt_output > > ieee80211_send_mgmt > > ieee80211_newstate wi_newstate() should probably call NET_LOCK_GIANT() before entering the 802.11 framework, and call NET_UNLOCK_GIANT() on its return. This will cause it to conditionally acquire and release Giant based on debug_mpsafenet. > I can't see how the acpi commit affects this. The assertion is in the > if code so it's likely that wi(4) is not setting the right flag to > acquire Giant before if_start. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 23:38:42 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 D972416A4CF for ; Mon, 16 Aug 2004 23:38:42 +0000 (GMT) Received: from mail.dada.it (mail2.dada.it [195.110.100.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 30C9743D41 for ; Mon, 16 Aug 2004 23:38:37 +0000 (GMT) (envelope-from riccardo@torrini.org) Received: (qmail 21287 invoked from network); 16 Aug 2004 23:38:32 -0000 Received: from unknown (HELO silos.torrini.home) (195.110.114.101) by mail.dada.it with SMTP; 16 Aug 2004 23:38:32 -0000 Received: from trudy.torrini.home (trudy.torrini.home [192.168.22.3]) by silos.torrini.home (Postfix) with ESMTP id 03DD4A91B; Tue, 17 Aug 2004 01:38:33 +0200 (CEST) Received: by trudy.torrini.home (Postfix, from userid 1001) id 6B7DF1F36; Tue, 17 Aug 2004 01:38:33 +0200 (CEST) Date: Tue, 17 Aug 2004 01:38:33 +0200 From: Riccardo Torrini To: Nate Lawson Message-ID: <20040816233833.GA651@trudy.torrini.home> References: <20040815223335.GA82743@trudy.torrini.home> <41203316.90801@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41203316.90801@root.org> User-Agent: Mutt/1.5.6i cc: acpi@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: Disabled known-bad BIOS revisions 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, 16 Aug 2004 23:38:43 -0000 On Sun, Aug 15, 2004 at 09:07:50PM -0700, Nate Lawson wrote: > Try booting with "unset acpi_load" so that acpi is not even loaded. Ahemmm, I'm sorry, but I read the next message and updated my BIOS before any other test :-( Anyway with kernel/world after end of june it boot only if: - add hint.acpi.0.disabled="0" or - use a kernel _without_ option SMP/option apic > Does your system work then? If so, the problem that needs to be > fixed is booting with ACPI disabled and is a bug. I find it hard > to believe that your system was designed to not work without ACPI > since it is from 1999. After a BIOS upgrade it works so I think it doesn't matter. If you really need a report from my old bios I'd think to revert to old one (but only if you _really_ _really_ need it :-) >> (only a "don't know if related" problem: after switching to sound >> and snd_* my machine don't play any sound, device is found at boot >> but no mixer nor dsp are created into /dev ... No need for this, found and solved. With old drivers my AWE/64 use sbc, now it need sb16. Don't ask me why. Sorry for wasting time. Maybe I'm wrong again but I kldloaded snd_driver so I now have both of them (snd_sbc compiled into the kernel and snd_sb16 loaded as module). Reading again NOTES give me a hint: I need both? >> Can I vote for "removing" this MoBo from quirks? > No, the hints give the same behavior you'd have on ... OtherOS ... No need to remove. It is a specific version that broke ACPI boot. After an update from 1014.beta001a to 1014.beta003 works again. Thanks for your time. -- Riccardo. ( http://www.GUFI.org/~vic/ ) From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 23:46: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 9062B16A4D0 for ; Mon, 16 Aug 2004 23:46:55 +0000 (GMT) Received: from mail.dada.it (mail2.dada.it [195.110.100.2]) by mx1.FreeBSD.org (Postfix) with SMTP id D67A643D39 for ; Mon, 16 Aug 2004 23:46:54 +0000 (GMT) (envelope-from riccardo@torrini.org) Received: (qmail 23204 invoked from network); 16 Aug 2004 23:46:50 -0000 Received: from unknown (HELO silos.torrini.home) (195.110.114.101) by mail.dada.it with SMTP; 16 Aug 2004 23:46:50 -0000 Received: from trudy.torrini.home (trudy.torrini.home [192.168.22.3]) by silos.torrini.home (Postfix) with ESMTP id BD0B0A91B; Tue, 17 Aug 2004 01:46:52 +0200 (CEST) Received: by trudy.torrini.home (Postfix, from userid 1001) id 4FCD01F36; Tue, 17 Aug 2004 01:46:52 +0200 (CEST) Date: Tue, 17 Aug 2004 01:46:52 +0200 From: Riccardo Torrini To: Daniel Eriksson Message-ID: <20040816234652.GB651@trudy.torrini.home> References: <41203316.90801@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Disabled known-bad BIOS revisions 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, 16 Aug 2004 23:46:55 -0000 On Mon, Aug 16, 2004 at 02:15:46PM +0200, Daniel Eriksson wrote: > Try upgrading your BIOS to the latest beta version. I'm running a > P2B-DS with ACPI enabled without any problems, using the 1014.003 > bios available here: > ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Slot_I/INTEL_Chipset/i440BX/P2B-DS/ Thanks. Really a good pointer. It solves. Now my machine boots without touching device.hint :) Only a side note: from my home netblock (both my static IP and proxy of my ISP) it is unavailable (unable to login) but from work I downloaded both BIOS and flash utility without problems. Both range are from Italy. Previous version 1014.beta001a fail with kernel after late june... -- Riccardo. ( http://www.GUFI.org/~vic/ ) From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 16 23:58:11 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 3DB6E16A4CE; Mon, 16 Aug 2004 23:58:11 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0843743D48; Mon, 16 Aug 2004 23:58:11 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7GNw98U024893; Mon, 16 Aug 2004 16:58:10 -0700 Message-ID: <41214A0E.7040706@root.org> Date: Mon, 16 Aug 2004 16:58:06 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Riccardo Torrini References: <20040815223335.GA82743@trudy.torrini.home> <41203316.90801@root.org> <20040816233833.GA651@trudy.torrini.home> In-Reply-To: <20040816233833.GA651@trudy.torrini.home> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: Disabled known-bad BIOS revisions 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, 16 Aug 2004 23:58:11 -0000 Riccardo Torrini wrote: > On Sun, Aug 15, 2004 at 09:07:50PM -0700, Nate Lawson wrote: >>Try booting with "unset acpi_load" so that acpi is not even loaded. > > Ahemmm, I'm sorry, but I read the next message and updated my BIOS > before any other test :-( Anyway with kernel/world after end of > june it boot only if: > - add hint.acpi.0.disabled="0" > or > - use a kernel _without_ option SMP/option apic > >>Does your system work then? If so, the problem that needs to be >>fixed is booting with ACPI disabled and is a bug. I find it hard >>to believe that your system was designed to not work without ACPI >>since it is from 1999. > > After a BIOS upgrade it works so I think it doesn't matter. If you > really need a report from my old bios I'd think to revert to old one > (but only if you _really_ _really_ need it :-) > > No need to remove. It is a specific version that broke ACPI boot. > After an update from 1014.beta001a to 1014.beta003 works again. > > Thanks for your time. That's why the first advice in the ACPI debuging handbook entry is "upgrade your BIOS." :) It would be good to fix why we couldn't boot with acpi disabled on the old BIOS. I'm guessing it was an error in your system's MADT. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 01:48: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 A1A3316A4CE for ; Tue, 17 Aug 2004 01:48:34 +0000 (GMT) Received: from mail.omut.org (mail.omut.org [216.218.215.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73B4F43D1D for ; Tue, 17 Aug 2004 01:48:34 +0000 (GMT) (envelope-from lxv@omut.org) Received: from tadpole.intranet (mix-anchor.intranet [10.10.10.251]) by mail.omut.org (8.13.1/8.13.1) with ESMTP id i7H1mW3h020980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Aug 2004 18:48:33 -0700 (PDT) (envelope-from lxv@omut.org) Received: from tadpole.intranet (localhost [127.0.0.1]) by tadpole.intranet (8.13.1/8.13.1) with ESMTP id i7H1mVf8013381 for ; Mon, 16 Aug 2004 21:48:31 -0400 (EDT) (envelope-from lxv@tadpole.intranet) Received: (from lxv@localhost) by tadpole.intranet (8.13.1/8.13.1/Submit) id i7H1mVu2013373 for acpi@freebsd.org; Mon, 16 Aug 2004 21:48:31 -0400 (EDT) (envelope-from lxv) Date: Mon, 16 Aug 2004 21:48:30 -0400 From: Alex Vasylenko To: acpi@freebsd.org Message-ID: <20040817014828.GA12921@tadpole.intranet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.44 Subject: LOR (drm,acpi) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alex Vasylenko List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2004 01:48:34 -0000 The following was reported when leaving X on FreeBSD 5.2-CURRENT #6: Sat Aug 14 09:23:46 EDT 2004: lock order reversal 1st 0xc18ae064 drm device (drm device) @ @/dev/drm/drm_irq.h:192 2nd 0xc0872060 ACPI root bus (ACPI root bus) @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841 KDB: stack backtrace: kdb_backtrace(c06c0eb4,c0872060,c086c28e,c086c28e,c086c693) at kdb_backtrace+0x2e witness_checkorder(c0872060,9,c086c693,349,c06f0bc4) at witness_checkorder+0x6a6 _sx_xlock(c0872060,c086c693,349,c06f0ba0,40) at _sx_xlock+0x7e acpi_release_resource(c1794680,c1742a00,1,0,c18046c0) at acpi_release_resource+0x2b bus_generic_release_resource(c1742e00,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 resource_list_release(c1794084,c1801d00,c1742a00,1,0) at resource_list_release+0x84 bus_generic_rl_release_resource(c1801d00,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 bus_generic_release_resource(c1802080,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 resource_list_release(c1794084,c1742e80,c1742a00,1,0) at resource_list_release+0x13b bus_generic_rl_release_resource(c1742e80,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 bus_release_resource(c1742a00,1,0,c18046c0,c18ae064) at bus_release_resource+0x7f radeon_irq_uninstall(c18ae000,0,c1d85640,c0,c1d88130) at radeon_irq_uninstall+0x7b radeon_control(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_control+0x8d radeon_ioctl(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_ioctl+0x1f6 spec_ioctl(d5de0b80,d5de0c2c,c0590fc1,d5de0b80,1) at spec_ioctl+0x1ce spec_vnoperate(d5de0b80,1,c06c6266,30e,c070f8a0) at spec_vnoperate+0x18 vn_ioctl(c19acd48,80086414,d5de0c58,c1d91480,c19a22c0) at vn_ioctl+0x1c1 ioctl(c19a22c0,d5de0d14,c,437,3) at ioctl+0x4f2 syscall(2840002f,bfbf002f,bfbf002f,8945400,8734000) at syscall+0x2a0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2827000f, esp = 0xbfbfeadc, ebp = 0xbfbfeaf8 --- From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 08:59: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 576FD16A4CE; Tue, 17 Aug 2004 08:59:18 +0000 (GMT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 407C043D70; Tue, 17 Aug 2004 08:59:17 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id RAA16726; Tue, 17 Aug 2004 17:59:13 +0900 (JST) Message-Id: <200408170859.RAA16726@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: Niki Denev From: takawata@jp.freebsd.org In-reply-to: Your message of "Tue, 17 Aug 2004 10:35:17 +0300." Date: Tue, 17 Aug 2004 17:59:12 +0900 Sender: takawata@axe-inc.co.jp cc: freebsd-hackers@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: Driver for Thinkpad Hotkeys. 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, 17 Aug 2004 08:59:18 -0000 I updated the driver to be able to change wireless status, by dev.acpi_tpkey.0.bluetooth, dev.acpi_tpkey.0.wlan sysctl value. (WLAN handling may not be correct.) http://www.init-main.com/acpi_tpkey/acpi_tpkey.c In message , Niki Denev wrote: >On my X31, when i load acpi_tpkey and start 'devd -dD', i get notifications >only when pressing the Fn+F3 (screen blank) combination. >Am i missing something ? By default,only Fn+F3,Fn+F4(Suspend - This is handled by this driver, instead of sleep button driver), and Fn+F12(Suspend to Disk) will assert notification. In addition to that, you can transfer control of all *possible* button to operating system by setting dev.acpi_tpkey.0.key_mask to dev.acpi_tpkey.0.avail_mask. This will enable all notifications and disable all default hotkey actions. >P.S.: the acpi_tpkey_kldload.out file contains the console output, when i >load the driver. >and the acpi_tpkey_notify.out file contains the message i get when pressing >Fn+F3. >Any other special buttons, (AccessIBM, vol up/down, mute, brightness, key >light) don't print notify messages, but they continue to work normal. That's expected. Those button will not produce any ACPI notification, though it is dealt by ACPI byte code. Instead of it, those keys set toggle value to RTC ram and you can access the Fn+SPC(0x20) and AccessIBM(0x8) value by dev.acpi_tpkey.0.misckey . (Volume and Brightness toggle can be seen in RTC register, but it is not exported to user now.) To assert event from kernel, kernel thread will be needed. From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 09:14: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 5F21A16A4CF for ; Tue, 17 Aug 2004 09:14:55 +0000 (GMT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D2D743D64 for ; Tue, 17 Aug 2004 09:14:54 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 28328 invoked from network); 17 Aug 2004 09:14:52 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-4.9/8.0):. Processed in 2.313352 secs); 17 Aug 2004 09:14:52 -0000 X-Spam-Status: No, hits=-4.9 required=8.0 Received: from 213-240-202-139.1697748.ddns.cablebg.net (HELO tormentor.totalterror.net) (213.240.202.139) by mail.interbgc.com with SMTP; 17 Aug 2004 09:14:49 -0000 Received: (qmail 87047 invoked from network); 17 Aug 2004 09:17:56 -0000 Received: from unknown (HELO phobos.totalterror.net) (10.0.0.2) by tormentor.totalterror.net with SMTP; 17 Aug 2004 09:17:55 -0000 References: <200408170859.RAA16726@axe-inc.co.jp> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Niki Denev To: takawata@jp.freebsd.org Date: Tue, 17 Aug 2004 12:14:48 +0300 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-phobos.totalterror.net-782-1092734088-0002"; micalg=pgp-sha1; protocol="application/pgp-signature" cc: freebsd-hackers@freebsd.org cc: freebsd-acpi@freebsd.org Subject: Re: Driver for Thinkpad Hotkeys. 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, 17 Aug 2004 09:14:55 -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-782-1092734088-0002 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit takawata@jp.freebsd.org writes: > I updated the driver to be able to change wireless status, by > dev.acpi_tpkey.0.bluetooth, > dev.acpi_tpkey.0.wlan > sysctl value. (WLAN handling may not be correct.) > http://www.init-main.com/acpi_tpkey/acpi_tpkey.c > > In message , Niki Denev > wrote: >>On my X31, when i load acpi_tpkey and start 'devd -dD', i get notifications >>only when pressing the Fn+F3 (screen blank) combination. >>Am i missing something ? > > By default,only Fn+F3,Fn+F4(Suspend - This is handled by this driver, > instead of sleep button driver), and Fn+F12(Suspend to Disk) > will assert notification. > In addition to that, you can transfer control of all *possible* button > to operating system by setting dev.acpi_tpkey.0.key_mask > to dev.acpi_tpkey.0.avail_mask. > This will enable all notifications and disable all default hotkey actions. > > > >>P.S.: the acpi_tpkey_kldload.out file contains the console output, when i >>load the driver. >>and the acpi_tpkey_notify.out file contains the message i get when pressing >>Fn+F3. >>Any other special buttons, (AccessIBM, vol up/down, mute, brightness, key >>light) don't print notify messages, but they continue to work normal. > > That's expected. Those button will not produce any ACPI notification, > though it is dealt by ACPI byte code. > Instead of it, those keys set toggle value to RTC ram and you can access > the Fn+SPC(0x20) and AccessIBM(0x8) value by dev.acpi_tpkey.0.misckey . > (Volume and Brightness toggle can be seen in RTC register, but > it is not exported to user now.) > To assert event from kernel, kernel thread will be needed. > > thanks for the clarification. - Niki --=_mimegpg-phobos.totalterror.net-782-1092734088-0002 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBIcyIHNAJ/fLbfrkRApWVAKCGiNg0hJFYD7mzAQJc68kZ1ZvAOACbBOi2 8uRjrHGcBGJvXcOYAsQvc34= =GpUL -----END PGP SIGNATURE----- --=_mimegpg-phobos.totalterror.net-782-1092734088-0002-- From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 18:08: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 5CA4C16A4CE; Tue, 17 Aug 2004 18:08:18 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26EA143D2F; Tue, 17 Aug 2004 18:08:18 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7HI8H8U015333; Tue, 17 Aug 2004 11:08:17 -0700 Message-ID: <41224990.9050008@root.org> Date: Tue, 17 Aug 2004 11:08:16 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Vasylenko References: <20040817014828.GA12921@tadpole.intranet> In-Reply-To: <20040817014828.GA12921@tadpole.intranet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: LOR (drm,acpi) 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, 17 Aug 2004 18:08:18 -0000 Alex Vasylenko wrote: > The following was reported when leaving X on FreeBSD 5.2-CURRENT #6: Sat Aug 14 09:23:46 EDT 2004: > > lock order reversal > 1st 0xc18ae064 drm device (drm device) @ @/dev/drm/drm_irq.h:192 > 2nd 0xc0872060 ACPI root bus (ACPI root bus) @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841 > KDB: stack backtrace: > kdb_backtrace(c06c0eb4,c0872060,c086c28e,c086c28e,c086c693) at kdb_backtrace+0x2e > witness_checkorder(c0872060,9,c086c693,349,c06f0bc4) at witness_checkorder+0x6a6 > _sx_xlock(c0872060,c086c693,349,c06f0ba0,40) at _sx_xlock+0x7e > acpi_release_resource(c1794680,c1742a00,1,0,c18046c0) at acpi_release_resource+0x2b > bus_generic_release_resource(c1742e00,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 > resource_list_release(c1794084,c1801d00,c1742a00,1,0) at resource_list_release+0x84 > bus_generic_rl_release_resource(c1801d00,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 > bus_generic_release_resource(c1802080,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 > resource_list_release(c1794084,c1742e80,c1742a00,1,0) at resource_list_release+0x13b > bus_generic_rl_release_resource(c1742e80,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 > bus_release_resource(c1742a00,1,0,c18046c0,c18ae064) at bus_release_resource+0x7f > radeon_irq_uninstall(c18ae000,0,c1d85640,c0,c1d88130) at radeon_irq_uninstall+0x7b > radeon_control(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_control+0x8d > radeon_ioctl(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_ioctl+0x1f6 > spec_ioctl(d5de0b80,d5de0c2c,c0590fc1,d5de0b80,1) at spec_ioctl+0x1ce > spec_vnoperate(d5de0b80,1,c06c6266,30e,c070f8a0) at spec_vnoperate+0x18 > vn_ioctl(c19acd48,80086414,d5de0c58,c1d91480,c19a22c0) at vn_ioctl+0x1c1 > ioctl(c19a22c0,d5de0d14,c,437,3) at ioctl+0x4f2 > syscall(2840002f,bfbf002f,bfbf002f,8945400,8734000) at syscall+0x2a0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2827000f, esp = 0xbfbfeadc, ebp = 0xbfbfeaf8 --- I can't see how the radeon and acpi locks are interrelated. Anyone else have an idea? The radeon call is just a simple: bus_release_resource(dev->device, SYS_RES_IRQ, irqrid, dev->irqr); Perhaps it's not ok to hold a sx lock while calling into the parent (from acpi.c): ret = BUS_RELEASE_RESOURCE(device_get_parent(bus), child, type, rid, r); -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 17 19:50:51 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 713C816A4CF; Tue, 17 Aug 2004 19:50:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EED3443D1F; Tue, 17 Aug 2004 19:50:50 +0000 (GMT) (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 i7HJnutS079283; Tue, 17 Aug 2004 13:49:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 17 Aug 2004 13:49:57 -0600 (MDT) Message-Id: <20040817.134957.35663556.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <41224990.9050008@root.org> References: <20040817014828.GA12921@tadpole.intranet> <41224990.9050008@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: acpi@freebsd.org cc: current@freebsd.org Subject: Re: LOR (drm,acpi) 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, 17 Aug 2004 19:50:51 -0000 In message: <41224990.9050008@root.org> Nate Lawson writes: : Alex Vasylenko wrote: : > The following was reported when leaving X on FreeBSD 5.2-CURRENT #6: Sat Aug 14 09:23:46 EDT 2004: : > : > lock order reversal : > 1st 0xc18ae064 drm device (drm device) @ @/dev/drm/drm_irq.h:192 : > 2nd 0xc0872060 ACPI root bus (ACPI root bus) @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841 : > KDB: stack backtrace: : > kdb_backtrace(c06c0eb4,c0872060,c086c28e,c086c28e,c086c693) at kdb_backtrace+0x2e : > witness_checkorder(c0872060,9,c086c693,349,c06f0bc4) at witness_checkorder+0x6a6 : > _sx_xlock(c0872060,c086c693,349,c06f0ba0,40) at _sx_xlock+0x7e : > acpi_release_resource(c1794680,c1742a00,1,0,c18046c0) at acpi_release_resource+0x2b : > bus_generic_release_resource(c1742e00,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 : > resource_list_release(c1794084,c1801d00,c1742a00,1,0) at resource_list_release+0x84 : > bus_generic_rl_release_resource(c1801d00,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 : > bus_generic_release_resource(c1802080,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82 : > resource_list_release(c1794084,c1742e80,c1742a00,1,0) at resource_list_release+0x13b : > bus_generic_rl_release_resource(c1742e80,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86 : > bus_release_resource(c1742a00,1,0,c18046c0,c18ae064) at bus_release_resource+0x7f : > radeon_irq_uninstall(c18ae000,0,c1d85640,c0,c1d88130) at radeon_irq_uninstall+0x7b : > radeon_control(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_control+0x8d : > radeon_ioctl(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_ioctl+0x1f6 : > spec_ioctl(d5de0b80,d5de0c2c,c0590fc1,d5de0b80,1) at spec_ioctl+0x1ce : > spec_vnoperate(d5de0b80,1,c06c6266,30e,c070f8a0) at spec_vnoperate+0x18 : > vn_ioctl(c19acd48,80086414,d5de0c58,c1d91480,c19a22c0) at vn_ioctl+0x1c1 : > ioctl(c19a22c0,d5de0d14,c,437,3) at ioctl+0x4f2 : > syscall(2840002f,bfbf002f,bfbf002f,8945400,8734000) at syscall+0x2a0 : > Xint0x80_syscall() at Xint0x80_syscall+0x1f : > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2827000f, esp = 0xbfbfeadc, ebp = 0xbfbfeaf8 --- : : I can't see how the radeon and acpi locks are interrelated. Anyone else : have an idea? The radeon call is just a simple: : : bus_release_resource(dev->device, SYS_RES_IRQ, irqrid, dev->irqr); : : Perhaps it's not ok to hold a sx lock while calling into the parent : (from acpi.c): : : ret = BUS_RELEASE_RESOURCE(device_get_parent(bus), child, type, rid, r); The lock is the ACPI root lock vs the drm lock. It appears that there are two different code paths, one of which takes the drm lock first, the other of which takes the acpi lock first. My guess is that the former is taken in the probe routine, while the latter is taken when reconfiguring itself via ioctl at runtime. One should look there for the problems. Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 18 00:23: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 9B03D16A4CE for ; Wed, 18 Aug 2004 00:23:17 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67FB343D1F for ; Wed, 18 Aug 2004 00:23:17 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7I0NG8U022515; Tue, 17 Aug 2004 17:23:16 -0700 Message-ID: <4122A173.6030100@root.org> Date: Tue, 17 Aug 2004 17:23:15 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hanspeter Roth References: <20040814163010.GA851@gicco.homeip.net> In-Reply-To: <20040814163010.GA851@gicco.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: suspend on Pavilion hangs 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, 18 Aug 2004 00:23:17 -0000 Hanspeter Roth wrote: > Hello, > > I have -current installed on an HP Pavillion zt3030EA. > Trying to suspend (S3) hangs. First this message is displayed: > > fwohci0: fwohci_pci_suspend > > Then the display is dimmed a little. Then the system hangs. > A longclick on the powerbutton shuts the laptop off. The next click > on the powerbutton turns on the power-led but nothing else happens. > Another longclick is required. Then the next click starts normal > boot. > > Does ACPI suspend rely on swapspace? Nope. > What happens if there are devices that have 'no driver attached'? Is > suspending still possible? Yep. > What if I remove some devices from the kernel that are not > necessarily needed? That's a good way to start debugging suspend/resume problems. For more info, see the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 18 09:16:44 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 B22AC16A4CE; Wed, 18 Aug 2004 09:16:44 +0000 (GMT) Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [202.0.58.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96D243D31; Wed, 18 Aug 2004 09:16:43 +0000 (GMT) (envelope-from info@mirdev.net) Received: from smtp-3.paradise.net.nz (smtp-3b.paradise.net.nz [202.0.32.212]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0I2M005VYXRUK3@linda-2.paradise.net.nz>; Wed, 18 Aug 2004 21:16:42 +1200 (NZST) Received: from pcmird (203-79-122-191.cable.paradise.net.nz [203.79.122.191]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id 6AA78AE75D; Wed, 18 Aug 2004 21:16:37 +1200 (NZST) Received: from 127.0.0.1 (AVG SMTP 6.0.0 [494]); Wed, 18 Aug 2004 21:16:30 +1200 Date: Wed, 18 Aug 2004 21:16:30 +1200 From: John Armstrong To: freebsd-current@freebsd.org Message-id: <41231E6E.80405@mirdev.net> MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------010706080102070700050003 X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) cc: freebsd-acpi@freebsd.org Subject: acpi link set: _CRS failed / calcru: negative runtime in -CURRENT 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, 18 Aug 2004 09:16:44 -0000 This is a multi-part message in MIME format. --------------010706080102070700050003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I recently decided to shift from 5.2.1p9 to 5.2-CURRENT on my home server, but I've been having trouble getting a fully bootable kernel, with the issue being a string of 'calcru: negative runtime' errors followed by a freeze after start_init even with a GENERIC kernel. I can however successfully boot with ACPI disabled, although that presents another problem as one of my NICs dies with no ACPI, *sigh* ;). Anyway, after a little hunt through dmesg I noted some ACPI errors when enabled: acpi link set: _CRS failed for link \_SB_.PCI0.ALKB - AE_NULL_ENTRY unknown: _SRS failed, irq 21 via \_SB_.PCI0.ALKB acpi link set: _CRS failed for link \_SB_.PCI0.ALKD - AE_NULL_ENTRY unknown: _SRS failed, irq 23 via \_SB_.PCI0.ALKD I'm taking a wild stab in the dark and guessing that the ACPI timer is going a little berserk which may be causing the negative runtime errors, although to tell the truth I'm a complete newbie as far as this sort of thing goes. Attached is the dmesg from a boot -v .. if there is anything else you'd like me to provide please let me know. Cheers, John Armstrong --------------010706080102070700050003 Content-Type: text/plain; name="server-dmesg-20040818.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="server-dmesg-20040818.log" Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #1: Wed Aug 18 18:00:57 NZST 2004 mird@server.homenet:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b85000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b85228. Calibrating clock(s) ... i8254 clock: 1193239 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 900005706 Hz CPU: AMD Duron(tm) processor (900.01-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183fbff AMD Features=0xc0440000 Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000001f6bffff, 514420736 bytes (125591 pages) avail memory = 515633152 (491 MB) Table 'FACP' at 0x1fff3040 Table 'APIC' at 0x1fff6fc0 MADT: Found table at 0x1fff6fc0 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00faf20 bios32: Entry = 0xfb390 (c00fb390) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb3c0 pnpbios: Found PnP BIOS data at 0xc00fbe90 pnpbios: Entry = f0000:bec0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=30991106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fdea0 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 9 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 D 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 16 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 16 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 16 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 16 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 2 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.0 \_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.1 \_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.2 \_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.3 \_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.17.0 \_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.17.1 \_SB_.PCI0.ALKC irq 0: [22] 0+ low,level,sharable 0.17.2 \_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.17.3 \_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.0 \_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.1 \_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.2 \_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x3099, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb099, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e4000000, size 24, enabled map[14]: type 1, range 32, base e5000000, size 14, enabled map[18]: type 1, range 32, base e6000000, size 23, enabled pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 16 found-> vendor=0x102b, dev=0x051b, revid=0x00 bus=0, slot=9, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 map[10]: type 4, range 32, base 0000c000, size 6, enabled pcib0: matched entry for 0.12.INTA pcib0: slot 12 INTA hardwired to IRQ 19 found-> vendor=0x10b7, dev=0x9050, revid=0x00 bus=0, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=19 map[10]: type 4, range 32, base 0000c400, size 8, enabled map[14]: type 1, range 32, base ffffff00, size 8, enabled pcib0: matched entry for 0.14.INTA pcib0: slot 14 INTA hardwired to IRQ 17 found-> vendor=0x1106, dev=0x3065, revid=0x43 bus=0, slot=14, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000c800, size 5, enabled pcib0: matched entry for 0.16.INTA (src \_SB_.PCI0.ALKB) pcib0: possible interrupts: 21 ACPI PCI link arbitrated settings: \_SB_.PCI0.ALKB (references 5, priority 250): interrupts: 21 penalty: 50 \_SB_.PCI0.ALKD (references 5, priority 250): interrupts: 23 penalty: 50 \_SB_.PCI0.ALKA (references 1, priority 10): interrupts: 20 penalty: 10 \_SB_.PCI0.ALKC (references 1, priority 10): interrupts: 22 penalty: 10 acpi link set: _CRS failed for link \_SB_.PCI0.ALKB - AE_NULL_ENTRY unknown: _SRS failed, irq 21 via \_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000cc00, size 5, enabled pcib0: matched entry for 0.16.INTB (src \_SB_.PCI0.ALKB) pcib0: slot 16 INTB is already routed to irq 0 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000d000, size 5, enabled pcib0: matched entry for 0.16.INTC (src \_SB_.PCI0.ALKB) pcib0: slot 16 INTC is already routed to irq 0 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ffffff00, size 8, enabled pcib0: matched entry for 0.16.INTD (src \_SB_.PCI0.ALKB) pcib0: slot 16 INTD is already routed to irq 0 found-> vendor=0x1106, dev=0x3104, revid=0x82 bus=0, slot=16, func=3 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=0 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1106, dev=0x3177, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled map[14]: type 1, range 32, base ffffff00, size 8, enabled pcib0: matched entry for 0.18.INTA (src \_SB_.PCI0.ALKD) pcib0: possible interrupts: 23 ACPI PCI link arbitrated settings: \_SB_.PCI0.ALKD (references 5, priority 500): interrupts: 23 penalty: 100 \_SB_.PCI0.ALKA (references 1, priority 20): interrupts: 20 penalty: 20 \_SB_.PCI0.ALKC (references 1, priority 20): interrupts: 22 penalty: 20 \_SB_.PCI0.ALKB (references 5, priority 0): interrupts: 21 penalty: 100 acpi link set: _CRS failed for link \_SB_.PCI0.ALKD - AE_NULL_ENTRY unknown: _SRS failed, irq 23 via \_SB_.PCI0.ALKD found-> vendor=0x1106, dev=0x3065, revid=0x74 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x13f6, dev=0x0111, revid=0x10 bus=0, slot=19, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x18 (6000 ns) intpin=a, irq=19 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfff00000-0xfffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 pci0: at device 9.0 (no driver attached) xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xc000-0xc03f irq 19 at device 12.0 on pci0 xl0: Reserved 0x40 bytes for rid 0x10 type 4 at 0xc000 xl0: using port I/O xl0: media options word: e040 xl0: found MII/AUTO miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:60:08:2f:27:05 xl0: [GIANT-LOCKED] vr0: port 0xc400-0xc4ff mem 0xffffff00-0xffffffff irq 17 at device 14.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc400 miibus1: on vr0 ukphy0: on miibus1 ukphy0: OUI 0x0005be, model 0x0008, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:05:5d:e0:a5:bf vr0: [GIANT-LOCKED] uhci0: port 0xc800-0xc81f irq 11 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xcc00-0xcc1f irq 0 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcc00 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd000-0xd01f irq 0 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 16.3 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xd400-0xd40f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd400 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=20 ostat1=30 ata1-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata1-slave: stat=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ata1: [MPSAFE] vr1: port 0xe000-0xe0ff mem 0xffffff00-0xffffffff irq 11 at device 18.0 on pci0 vr1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 miibus2: on vr1 ukphy1: on miibus2 ukphy1: OUI 0x004063, model 0x0032, rev. 5 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: bpf attached vr1: Ethernet address: 00:50:70:22:8c:70 vr1: [GIANT-LOCKED] pci0: at device 19.0 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0: irq maps: 0x5003 0x5013 0x5003 0x5003 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x5003 0x500b 0x5003 0x5003 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: SPP ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 plip0: bpf attached unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 12: ioport 0xcc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 900005706 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-slave: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: setting PIO4 on VIA 8235 chip ata0-master: setting UDMA33 on VIA 8235 chip ata0-slave: setting PIO4 on VIA 8235 chip ata0-slave: setting UDMA100 on VIA 8235 chip ad0: ATA-4 disk at ata0-master ad0: 2014MB (4124736 sectors), 4092 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/15/63 s:63 l:4124673 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 2111832576 end 2111864831 ad1: ATA-6 disk at ata0-slave ad1: 38166MB (78165360 sectors), 77545 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 11 (ISA IRQ 11) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 GEOM: Configure ad0s1a, start 0 length 1073741824 end 1073741823 GEOM: Configure ad0s1b, start 1073741824 length 268435456 end 1342177279 GEOM: Configure ad0s1c, start 0 length 2111832576 end 2111832575 GEOM: Configure ad0s1d, start 1342177280 length 268435456 end 1610612735 GEOM: Configure ad0s1e, start 1610612736 length 501219840 end 2111832575 GEOM: new disk ad1 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:78156162 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad1s1, start 32256 length 40015954944 end 40015987199 GEOM: Configure ad1s1c, start 0 length 40015954944 end 40015954943 GEOM: Configure ad1s1d, start 0 length 40015954944 end 40015954943 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init calcru: negative runtime of -941689 usec for pid 66 (rcorder) calcru: negative runtime of -647032 usec for pid 81 (sysctl) IP Filter: v3.4.35 initialized. Default = pass all, Logging = enabled calcru: negative runtime of -669025 usec for pid 198 (ipf) calcru: negative runtime of -419390 usec for pid 11 (idle: cpu0) calcru: negative runtime of -419390 usec for pid 11 (idle: cpu0) calcru: negative runtime of -991447 usec for pid 303 (sysctl) --------------010706080102070700050003-- From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 18 16:44: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 6493316A4CE; Wed, 18 Aug 2004 16:44:49 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2978943D1F; Wed, 18 Aug 2004 16:44:49 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7IGil8U013804; Wed, 18 Aug 2004 09:44:48 -0700 Message-ID: <41238213.6030804@root.org> Date: Wed, 18 Aug 2004 09:21:39 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Armstrong References: <41231E6E.80405@mirdev.net> In-Reply-To: <41231E6E.80405@mirdev.net> Content-Type: multipart/mixed; boundary="------------080601000100080201020602" cc: David Malone cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi link set: _CRS failed / calcru: negative runtime in -CURRENT 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, 18 Aug 2004 16:44:49 -0000 This is a multi-part message in MIME format. --------------080601000100080201020602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Armstrong wrote: > I recently decided to shift from 5.2.1p9 to 5.2-CURRENT on my home > server, but I've been having trouble getting a fully bootable kernel, > with the issue being a string of 'calcru: negative runtime' errors > followed by a freeze after start_init even with a GENERIC kernel. > > I can however successfully boot with ACPI disabled, although that > presents another problem as one of my NICs dies with no ACPI, *sigh* ;). > Anyway, after a little hunt through dmesg I noted some ACPI errors when > enabled: > > > acpi link set: _CRS failed for link \_SB_.PCI0.ALKB - AE_NULL_ENTRY > unknown: _SRS failed, irq 21 via \_SB_.PCI0.ALKB > acpi link set: _CRS failed for link \_SB_.PCI0.ALKD - AE_NULL_ENTRY > unknown: _SRS failed, irq 23 via \_SB_.PCI0.ALKD > > > I'm taking a wild stab in the dark and guessing that the ACPI timer is > going a little berserk which may be causing the negative runtime errors, > although to tell the truth I'm a complete newbie as far as this sort of > thing goes. > > Attached is the dmesg from a boot -v .. if there is anything else you'd > like me to provide please let me know. Try the patch I just committed (also attached). -Nate --------------080601000100080201020602 Content-Type: text/plain; name="link.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="link.diff" njl 2004-08-18 16:39:59 UTC FreeBSD src repository Modified files: sys/dev/acpica acpi_pci_link.c Log: If _CRS fails, assume that it succeeded. The ASUS K8V (and others) defines single-entry irq links even though it uses an APIC. It appears that it ignores _SRS when in APIC mode but returns a valid irq at other times. Revision Changes Path 1.25 +1 -2 src/sys/dev/acpica/acpi_pci_link.c Index: src/sys/dev/acpica/acpi_pci_link.c --- src/sys/dev/acpica/acpi_pci_link.c:1.24 Fri Aug 13 19:27:21 2004 +++ src/sys/dev/acpica/acpi_pci_link.c Wed Aug 18 16:39:59 2004 @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD: /repoman/r/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v 1.24 2004/08/13 19:27:21 njl Exp $"); +__FBSDID("$FreeBSD: /repoman/r/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v 1.25 2004/08/18 16:39:59 njl Exp $"); #include "opt_acpi.h" #include @@ -648,10 +648,9 @@ * assume we were successful. */ error = acpi_pci_link_get_current_irq(link, &link->current_irq); - if (ACPI_FAILURE(error)) { + if (ACPI_FAILURE(error) && bootverbose) { printf("acpi link set: _CRS failed for link %s - %s\n", acpi_name(link->handle), AcpiFormatException(error)); - goto out; } if (link->current_irq != irq) { printf("acpi link set: curr irq %d != %d for %s (ignoring)\n", --------------080601000100080201020602-- From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 19 01:15: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 E4AB316A4CE; Thu, 19 Aug 2004 01:15:27 +0000 (GMT) Received: from linda-1.paradise.net.nz (bm-1a.paradise.net.nz [202.0.58.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39FE543D39; Thu, 19 Aug 2004 01:15:27 +0000 (GMT) (envelope-from info@mirdev.net) Received: from smtp-3.paradise.net.nz (smtp-3b.paradise.net.nz [202.0.32.212]) by linda-1.paradise.net.nz (Paradise.net.nz) with ESMTP id <0I2O003Q665PFQ@linda-1.paradise.net.nz>; Thu, 19 Aug 2004 13:15:25 +1200 (NZST) Received: from pcmird (203-79-122-191.cable.paradise.net.nz [203.79.122.191]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id AE5FEAE11C; Thu, 19 Aug 2004 13:15:24 +1200 (NZST) Received: from 127.0.0.1 (AVG SMTP 6.0.0 [494]); Thu, 19 Aug 2004 13:15:17 +1200 Date: Thu, 19 Aug 2004 13:15:16 +1200 From: John Armstrong In-reply-to: <41238213.6030804@root.org> To: freebsd-current@freebsd.org Message-id: <4123FF24.2050504@mirdev.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) References: <41231E6E.80405@mirdev.net> <41238213.6030804@root.org> cc: freebsd-acpi@freebsd.org Subject: Re: acpi link set: _CRS failed / calcru: negative runtime in -CURRENT 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, 19 Aug 2004 01:15:28 -0000 Nate Lawson wrote: > Try the patch I just committed (also attached). Thanks Nate, that worked a treat :) Cheers, John Armstrong From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 19 16:39: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 D4A7F16A4CE; Thu, 19 Aug 2004 16:39:47 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C6DB43D2D; Thu, 19 Aug 2004 16:39:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7JGco8U010050; Thu, 19 Aug 2004 09:39:45 -0700 Message-ID: <4124C910.3010304@root.org> Date: Thu, 19 Aug 2004 08:36:48 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Armstrong References: <41231E6E.80405@mirdev.net> <41238213.6030804@root.org> <4123FF24.2050504@mirdev.net> In-Reply-To: <4123FF24.2050504@mirdev.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi link set: _CRS failed / calcru: negative runtime in -CURRENT 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, 19 Aug 2004 16:39:48 -0000 John Armstrong wrote: > Nate Lawson wrote: > >> Try the patch I just committed (also attached). > > > Thanks Nate, that worked a treat :) You're welcome, thanks for testing. -Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 20 00:19: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 D898416A4CF; Fri, 20 Aug 2004 00:19:23 +0000 (GMT) Received: from bgezal.rise.tuwien.ac.at (bgezal.rise.tuwien.ac.at [128.130.59.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6426F43D49; Fri, 20 Aug 2004 00:19:23 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by bgezal.rise.tuwien.ac.at (Postfix) with ESMTP id A841F20AC; Fri, 20 Aug 2004 02:19:21 +0200 (CEST) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 610DD4110; Fri, 20 Aug 2004 02:19:01 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id A503E109; Tue, 17 Aug 2004 14:36:27 +0200 (CEST) Date: Tue, 17 Aug 2004 14:36:26 +0200 From: Stefan Farfeleder To: Robert Watson Message-ID: <20040817123623.GA622@wombat.fafoe.narf.at> Mail-Followup-To: Robert Watson , Nate Lawson , acpi@freebsd.org, current@freebsd.org References: <4120F26B.1040808@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: HEADSUP: acpi mpsafe committed 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, 20 Aug 2004 00:19:24 -0000 On Mon, Aug 16, 2004 at 02:33:30PM -0400, Robert Watson wrote: > > > panic: mutex Giant not owned at /usr/src/sys/net/if.c:1874 > > > > > > db> trace > > > kdb_enter > > > panic > > > _mtx_assert > > > if_start > > > ieee80211_mgmt_output > > > ieee80211_send_mgmt > > > ieee80211_newstate > > wi_newstate() should probably call NET_LOCK_GIANT() before entering the > 802.11 framework, and call NET_UNLOCK_GIANT() on its return. This will > cause it to conditionally acquire and release Giant based on > debug_mpsafenet. I have no idea why, but suspending suddenly works again with a new kernel. Sorry for the noise. Stefan From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 20 23:12:31 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 0C5B116A4D4 for ; Fri, 20 Aug 2004 23:12:31 +0000 (GMT) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2871143D5C for ; Fri, 20 Aug 2004 23:12:30 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (80-218-73-163.dclient.hispeed.ch [80.218.73.163])i7KNCS9v001846 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 21 Aug 2004 01:12:28 +0200 Received: from localhost.here (idefix@gicco.homeip.net [127.0.0.1]) by gicco.homeip.net (8.12.8p2/8.12.8) with ESMTP id i7KNCSAZ004014 for ; Sat, 21 Aug 2004 01:12:28 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by localhost.here (8.12.8p2/8.12.8/Submit) id i7KNCRhF004013 for freebsd-acpi@freebsd.org; Sat, 21 Aug 2004 01:12:27 +0200 (CEST) X-Authentication-Warning: localhost.here: idefix set sender to hampi@rootshell.be using -f Date: Sat, 21 Aug 2004 01:12:27 +0200 From: Hanspeter Roth To: freebsd-acpi@freebsd.org Message-ID: <20040820231227.GA3956@gicco.homeip.net> Mail-Followup-To: freebsd-acpi@freebsd.org References: <20040814163010.GA851@gicco.homeip.net> <4122A173.6030100@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4122A173.6030100@root.org> User-Agent: Mutt/1.4.1i Subject: Re: suspend on Pavilion hangs 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, 20 Aug 2004 23:12:31 -0000 On Aug 17 at 17:23, Nate Lawson spoke: > Hanspeter Roth wrote: > >What if I remove some devices from the kernel that are not > >necessarily needed? > > That's a good way to start debugging suspend/resume problems. For more > info, see the handbook: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html I have removed some devices. But still the laptop hangs on suspend. The output is now: acpi_lid0: wake_prep enabled for \_SB_.C136 (S3) ======== acpi_printcpu() debug dump ======== [...] It shows acpi_lid0 even though I have not used the lid switch but acpiconf -s 3. Is there something else I can try? Dmesg, sysctl.acpi and acpidump are available at: http://home.datacomm.ch/hampi/pavilion/ -Hanspeter From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 06:39: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 7202916A4CE for ; Sat, 21 Aug 2004 06:39:55 +0000 (GMT) Received: from st68.arena.ne.jp (st68.arena.ne.jp [203.138.213.2]) by mx1.FreeBSD.org (Postfix) with SMTP id AD32743D53 for ; Sat, 21 Aug 2004 06:39:54 +0000 (GMT) (envelope-from eyes@navi.org) Received: (qmail 15646 invoked by SAV 20040820.19); 21 Aug 2004 15:39:53 +0900 Received: from unknown (HELO localhost) (220.108.97.40) by st68.arena.ne.jp (203.138.213.118) with SMTP; 21 Aug 2004 15:39:53 +0900 Date: Sat, 21 Aug 2004 15:40:03 +0900 To: freebsd-acpi@freebsd.org From: "Hiroyuki Aizu" Organization: navi.org Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-2022-jp MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Message-ID: User-Agent: Opera M2/7.54 (FreeBSD, build 751) Subject: [PATCH] Some devices does not resetting IRQ after suspend/resume with ACPI. 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, 21 Aug 2004 06:39:55 -0000 Hi. I need the patch against acpi_pci_link.c like bellow. Because some devices does not resetting IRQ after suspend/resume on my Libretto L5. I try on recent 6-current. It looks like just typo. It occurs modify of acpi_pci_link.c between rev 1.18 and 1.19, the "Re-work ACPI PCI IRQ routing". Please apply the patch to 6-current and 5-stable. Thanks. -- Hiroyuki Aizu --- sys/dev/acpica/acpi_pci_link.c.origFri Aug 20 22:56:32 2004 +++ sys/dev/acpica/acpi_pci_link.cSat Aug 21 14:39:34 2004 @@ -1018,7 +1018,7 @@ acpi_pci_link_resume(device_t dev) /* Walk through all PRT entries for this PCI bridge. */ ACPI_SERIAL_BEGIN(pci_link); TAILQ_FOREACH(entry, &acpi_prt_entries, links) { - if (entry->pcidev =3D=3D dev || entry->pci_link =3D=3D NULL) + if (entry->pcidev !=3D dev || entry->pci_link =3D=3D NULL) continue; link =3D entry->pci_link; From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 09:05:41 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 3816316A4CE for ; Sat, 21 Aug 2004 09:05:41 +0000 (GMT) Received: from fbihome.de (stud.fbi.fh-darmstadt.de [141.100.40.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6DA243D1F for ; Sat, 21 Aug 2004 09:05:39 +0000 (GMT) (envelope-from dino@xrays.de) Received: from localhost (localhost [127.0.0.1]) by fbihome.de (Postfix) with ESMTP id B85FB932CD for ; Sat, 21 Aug 2004 11:09:30 +0200 (CEST) Received: from fbihome.de ([127.0.0.1]) by localhost (stud1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27952-17 for ; Sat, 21 Aug 2004 11:09:30 +0200 (CEST) Received: from [10.10.10.9] (unknown [84.135.189.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fbihome.de (Postfix) with ESMTP id D2D6D932BF for ; Sat, 21 Aug 2004 11:09:28 +0200 (CEST) Message-ID: <4127107C.9040209@xrays.de> Date: Sat, 21 Aug 2004 11:06:04 +0200 From: Corrado Ficicchia User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040801) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: multipart/mixed; boundary="------------050702080206080109020807" X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at fbihome.de Subject: _CRS failed for link 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, 21 Aug 2004 09:05:41 -0000 This is a multi-part message in MIME format. --------------050702080206080109020807 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I cvssuped yesterday from -current 15.Jul to 5.3 ALPHA. Since that, my vr NIC doesn't work anymore, telling me "vr0: watchdog timeout". Looking to my boot messages, I found this: acpi link set: _CRS failed for link \\_SB_.PCI0.ALKD - AE_NULL_ENTRY acpi link set: curr irq 0 != 23 for \\_SB_.PCI0.ALKD (ignoring) unknown: _SRS failed, irq 23 via \\_SB_.PCI0.ALKD found-> vendor=0x1106, dev=0x3065, revid=0x78 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 My 21.Jul kernel dumps this: pcib0: matched entry for 0.18.INTA (src \\_SB_.PCI0.ALKD) pcib0: possible interrupts: 23 pcib0: slot 18 INTA routed to irq 23 via \\_SB_.PCI0.ALKD found-> vendor=0x1106, dev=0x3065, revid=0x78 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=23 powerspec 2 supports D0 D1 D2 D3 current D0 I don't absolutely know if my problem is acpi related, for me it seems so. Any ideas? Dino --------------050702080206080109020807 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg" Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-ALPHA #1: Fri Aug 20 15:17:53 CEST 2004 root@fomp:/usr/obj/usr/src/sys/FOMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0790000. Preloaded elf module "/boot/kernel/ng_bpf.ko" at 0xc0790244. Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc07902f0. Preloaded elf module "/boot/kernel/ng_ether.ko" at 0xc07903a0. Preloaded elf module "/boot/kernel/ng_iface.ko" at 0xc0790450. Preloaded elf module "/boot/kernel/ng_ppp.ko" at 0xc0790500. Preloaded elf module "/boot/kernel/ng_pppoe.ko" at 0xc07905ac. Preloaded elf module "/boot/kernel/ng_socket.ko" at 0xc079065c. Preloaded elf module "/boot/kernel/ng_vjc.ko" at 0xc079070c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07907b8. Table 'FACP' at 0xeff3040 Table 'APIC' at 0xeff7cc0 MADT: Found table at 0xeff7cc0 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193014 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1197962949 Hz CPU: AMD Duron(tm) processor (1197.96-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 251592704 (239 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x000000000eb87fff, 238428160 bytes (58210 pages) avail memory = 240726016 (229 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf60 bios32: Entry = 0xfb3d0 (c00fb3d0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb420 pnpbios: Found PnP BIOS data at 0xc00fbf00 pnpbios: Entry = f0000:bf30 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> io: mem: Pentium Pro MTRR support enabled null: random: ath_hal: version 0.9.6.3 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=32051106) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00fdee0 PCI-Only Interrupts: 5 10 11 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 17 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 15 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.0 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.1 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.2 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.3 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.17.0 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.17.1 \\_SB_.PCI0.ALKC irq 0: [22] 0+ low,level,sharable 0.17.2 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.17.3 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.0 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.1 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.2 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.3 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.15.0 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.15.1 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.15.2 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.15.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e6000000, size 22, enabled found-> vendor=0x1106, dev=0x3205, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb198, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0xa230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base e6400000, size 16, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 16 found-> vendor=0x168c, dev=0x0013, revid=0x01 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base e6410000, size 11, enabled map[14]: type 4, range 32, base 00009000, size 7, enabled pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 17 found-> vendor=0x1106, dev=0x3044, revid=0x80 bus=0, slot=9, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=17 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 4, range 32, base 00009400, size 3, enabled map[14]: type 4, range 32, base 00009800, size 2, enabled map[18]: type 4, range 32, base 00009c00, size 3, enabled map[1c]: type 4, range 32, base 0000a000, size 2, enabled map[20]: type 4, range 32, base 0000a400, size 4, enabled map[24]: type 4, range 32, base 0000a800, size 8, enabled pcib0: matched entry for 0.15.INTB (src \\_SB_.PCI0.ALKA) pcib0: possible interrupts: 20 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ALKB (references 5, priority 250): interrupts: 21 penalty: 50 \\_SB_.PCI0.ALKA (references 5, priority 250): interrupts: 20 penalty: 50 \\_SB_.PCI0.ALKD (references 5, priority 250): interrupts: 23 penalty: 50 \\_SB_.PCI0.ALKC (references 1, priority 10): interrupts: 22 penalty: 10 acpi link set: _CRS failed for link \\_SB_.PCI0.ALKA - AE_NULL_ENTRY acpi link set: curr irq 0 != 20 for \\_SB_.PCI0.ALKA (ignoring) unknown: _SRS failed, irq 20 via \\_SB_.PCI0.ALKA found-> vendor=0x1106, dev=0x3149, revid=0x80 bus=0, slot=15, func=0 class=01-04-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000ac00, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=15, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3227, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000c000, size 8, enabled map[14]: type 1, range 32, base e6412000, size 8, enabled pcib0: matched entry for 0.18.INTA (src \\_SB_.PCI0.ALKD) pcib0: possible interrupts: 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ALKB (references 5, priority 500): interrupts: 21 penalty: 100 \\_SB_.PCI0.ALKD (references 5, priority 500): interrupts: 23 penalty: 100 \\_SB_.PCI0.ALKC (references 1, priority 20): interrupts: 22 penalty: 20 acpi link set: _CRS failed for link \\_SB_.PCI0.ALKD - AE_NULL_ENTRY acpi link set: curr irq 0 != 23 for \\_SB_.PCI0.ALKD (ignoring) unknown: _SRS failed, irq 23 via \\_SB_.PCI0.ALKD found-> vendor=0x1106, dev=0x3065, revid=0x78 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe6000000-0xe63fffff at device 0.0 on pci0 agp0: Reserved 0x400000 bytes for rid 0x10 type 3 at 0xe6000000 agp0: allocating GATT for aperture of size 255M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe4000000-0xe5ffffff pcib1: prefetched decode 0xe0000000-0xe3ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e0000000, size 26, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe3ffffff map[14]: type 1, range 32, base e4000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xe4000000-0xe4ffffff pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x1106, dev=0x7205, revid=0x01 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) ath0: mem 0xe6400000-0xe640ffff irq 16 at device 8.0 on pci0 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe6400000 ath0: [GIANT-LOCKED] ath0: mac 5.9 phy 4.3 5ghz radio 4.6 ath0: bpf attached ath0: Ethernet address: 00:0f:3d:86:cc:ab ath0: bpf attached ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: bpf attached pci0: at device 9.0 (no driver attached) atapci0: port 0xa800-0xa8ff,0xa400-0xa40f,0xa000-0xa003,0x9c00-0x9c07,0x9800-0x9803,0x9400-0x9407 irq 10 at device 15.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xa400 atapci0: [MPSAFE] ata2: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x9400 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x9800 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata2-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata3: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x9c00 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xa000 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-master: stat=0x7f err=0xff lsb=0xff msb=0xff ata3-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] atapci1: port 0xac00-0xac0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xac00 ata0: channel #0 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=20 ostat1=30 ata1-master: stat=0x20 err=0x20 lsb=0x20 msb=0x20 ata1-slave: stat=0x30 err=0x30 lsb=0x30 msb=0x30 ata1: reset tp2 stat0=20 stat1=30 devices=0x0 ata1: [MPSAFE] isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xc000-0xc0ff mem 0xe6412000-0xe64120ff irq 11 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc000 miibus0: on vr0 ukphy0: on miibus0 ukphy0: OUI 0x004063, model 0x0032, rev. 8 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:e0:4c:bb:99:36 vr0: [GIANT-LOCKED] unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) psmcpnp0 irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0xffffffff (1) kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 6e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 6e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 6e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0 failed to probe at port 0x3f8 irq 4 flags 0x10 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1197962949 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = disabled lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 8237 chip ata0-master: setting UDMA100 on VIA 8237 chip ad0: ATA-7 disk at ata0-master ad0: 38204MB (78242976 sectors), 77622 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 10 (ISA IRQ 10) to cluster 0 ioapic0: routing intpin 11 (ISA IRQ 11) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 GEOM: new disk ad0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:78236487 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 40057081344 end 40057113599 GEOM: Configure ad0s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s1b, start 268435456 length 1073741824 end 1342177279 GEOM: Configure ad0s1c, start 0 length 40057081344 end 40057081343 GEOM: Configure ad0s1d, start 1342177280 length 1073741824 end 2415919103 GEOM: Configure ad0s1e, start 2415919104 length 1073741824 end 3489660927 GEOM: Configure ad0s1f, start 3489660928 length 10737418240 end 14227079167 GEOM: Configure ad0s1g, start 14227079168 length 25830002176 end 40057081343 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Linux ELF exec handler installed vr0: watchdog timeout --------------050702080206080109020807-- From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 10:56: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 C7FD716A4CE for ; Sat, 21 Aug 2004 10:56:52 +0000 (GMT) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2E7543D4C for ; Sat, 21 Aug 2004 10:56:51 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (80-218-73-163.dclient.hispeed.ch [80.218.73.163])i7LAuoBG021112 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 21 Aug 2004 12:56:50 +0200 Received: from localhost.here (idefix@gicco.homeip.net [127.0.0.1]) by gicco.homeip.net (8.12.8p2/8.12.8) with ESMTP id i7LAun37001726 for ; Sat, 21 Aug 2004 12:56:50 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by localhost.here (8.12.8p2/8.12.8/Submit) id i7LAujMm001725 for freebsd-acpi@freebsd.org; Sat, 21 Aug 2004 12:56:45 +0200 (CEST) X-Authentication-Warning: localhost.here: idefix set sender to hampi@rootshell.be using -f Date: Sat, 21 Aug 2004 12:56:45 +0200 From: Hanspeter Roth To: freebsd-acpi@freebsd.org Message-ID: <20040821105645.GM532@gicco.homeip.net> Mail-Followup-To: freebsd-acpi@freebsd.org References: <20040814163010.GA851@gicco.homeip.net> <4122A173.6030100@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4122A173.6030100@root.org> User-Agent: Mutt/1.4.1i Subject: Re: suspend on Pavilion hangs 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, 21 Aug 2004 10:56:52 -0000 On Aug 17 at 17:23, Nate Lawson spoke: > Hanspeter Roth wrote: > >Does ACPI suspend rely on swapspace? > > Nope. Where is the state of the machine stored in suspend mode S3? Is a special file allocated that requires enough free space (for saving RAM and the RAM of the video module)? -Hanspeter From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 18:25: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 8D8E116A4CE for ; Sat, 21 Aug 2004 18:25:52 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4721C43D48 for ; Sat, 21 Aug 2004 18:25:52 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7LIPp8U006495; Sat, 21 Aug 2004 11:25:51 -0700 Message-ID: <412793AF.3000601@root.org> Date: Sat, 21 Aug 2004 11:25:51 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hanspeter Roth References: <20040814163010.GA851@gicco.homeip.net> <4122A173.6030100@root.org> <20040821105645.GM532@gicco.homeip.net> In-Reply-To: <20040821105645.GM532@gicco.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: suspend on Pavilion hangs 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, 21 Aug 2004 18:25:52 -0000 Hanspeter Roth wrote: > On Aug 17 at 17:23, Nate Lawson spoke: > > >>Hanspeter Roth wrote: >> >>>Does ACPI suspend rely on swapspace? >> >>Nope. > > > Where is the state of the machine stored in suspend mode S3? Is a > special file allocated that requires enough free space (for saving > RAM and the RAM of the video module)? S3 is suspend to ram so the chipset keeps the refresh running. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 18:26:31 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 26A3116A4CE for ; Sat, 21 Aug 2004 18:26:31 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA6A543D2D for ; Sat, 21 Aug 2004 18:26:30 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7LIQS8U006505; Sat, 21 Aug 2004 11:26:30 -0700 Message-ID: <412793D5.7050808@root.org> Date: Sat, 21 Aug 2004 11:26:29 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hiroyuki Aizu References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: [PATCH] Some devices does not resetting IRQ aftersuspend/resume with ACPI. 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, 21 Aug 2004 18:26:31 -0000 Hiroyuki Aizu wrote: > Hi. > > I need the patch against acpi_pci_link.c like bellow. > Because some devices does not resetting IRQ > after suspend/resume on my Libretto L5. > I try on recent 6-current. > > It looks like just typo. It occurs modify of > acpi_pci_link.c between rev 1.18 and 1.19, > the "Re-work ACPI PCI IRQ routing". Thanks, your patch is correct. I have committed it and will MFC as soon as allowed by re@. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 18:33: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 2BF6816A4CF for ; Sat, 21 Aug 2004 18:33:32 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0081043D1F for ; Sat, 21 Aug 2004 18:33:32 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7LIXV8U006579; Sat, 21 Aug 2004 11:33:31 -0700 Message-ID: <4127957B.2050000@root.org> Date: Sat, 21 Aug 2004 11:33:31 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hanspeter Roth References: <20040814163010.GA851@gicco.homeip.net> <4122A173.6030100@root.org> <20040820231227.GA3956@gicco.homeip.net> In-Reply-To: <20040820231227.GA3956@gicco.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: suspend on Pavilion hangs 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, 21 Aug 2004 18:33:32 -0000 Hanspeter Roth wrote: > On Aug 17 at 17:23, Nate Lawson spoke: >>Hanspeter Roth wrote: >> >>>What if I remove some devices from the kernel that are not >>>necessarily needed? >> >>That's a good way to start debugging suspend/resume problems. For more >>info, see the handbook: >>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > > I have removed some devices. But still the laptop hangs on suspend. > The output is now: > > acpi_lid0: wake_prep enabled for \_SB_.C136 (S3) > ======== acpi_printcpu() debug dump ======== > [...] > > It shows acpi_lid0 even though I have not used the lid switch but > acpiconf -s 3. That message is totally normal and just means that your lid switch is being enabled to _wake_ the system. So if you suspend with 'zzz' or whatever, you can still wake via the lid. This can be disabled via a sysctl if you want. > Is there something else I can try? > > Dmesg, sysctl.acpi and acpidump are available at: > http://home.datacomm.ch/hampi/pavilion/ See if Linux works. In general, suspend/resume does not work on a lot of laptops including on Linux. The process for fixing it is simple: begin by auditing all device drivers and fixing their suspend/resume methods. Continue on to fix all X video drivers by getting the undocumented info from the manufacturers. As you can see, while simple, this is a lot of work. There are a few things we can do better (_SxD, D3 on suspend) and I'm working on those, but fixing 5.3 to be a stable release is much higher on the priority list right now. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 18:57: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 E121216A4CE for ; Sat, 21 Aug 2004 18:57:33 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B163B43D48 for ; Sat, 21 Aug 2004 18:57:33 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7LIvW8U006775; Sat, 21 Aug 2004 11:57:32 -0700 Message-ID: <41279B1C.6070100@root.org> Date: Sat, 21 Aug 2004 11:57:32 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Corrado Ficicchia References: <4127107C.9040209@xrays.de> In-Reply-To: <4127107C.9040209@xrays.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: _CRS failed for link 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, 21 Aug 2004 18:57:34 -0000 Corrado Ficicchia wrote: > Hi all, > > I cvssuped yesterday from -current 15.Jul to 5.3 ALPHA. Since that, my > vr NIC doesn't work anymore, telling me "vr0: watchdog timeout". > > Looking to my boot messages, I found this: > > acpi link set: _CRS failed for link \\_SB_.PCI0.ALKD - AE_NULL_ENTRY > acpi link set: curr irq 0 != 23 for \\_SB_.PCI0.ALKD (ignoring) > unknown: _SRS failed, irq 23 via \\_SB_.PCI0.ALKD > found-> vendor=0x1106, dev=0x3065, revid=0x78 > bus=0, slot=18, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) > lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 You need acpi_pci_link.c rev. 1.24.2.1. It was MFCd on Thu Aug 19 19:19:40 2004 UTC on the RELENG_5 branch. So cvsup to that and try again. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 21 19:59: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 DD98C16A4CE for ; Sat, 21 Aug 2004 19:59:06 +0000 (GMT) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CB0243D1D for ; Sat, 21 Aug 2004 19:59:05 +0000 (GMT) (envelope-from hampi@rootshell.be) Received: from gicco.homeip.net (80-218-73-163.dclient.hispeed.ch [80.218.73.163])i7LJx3BG016447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 21 Aug 2004 21:59:03 +0200 Received: from localhost.here (idefix@gicco.homeip.net [127.0.0.1]) by gicco.homeip.net (8.12.8p2/8.12.8) with ESMTP id i7LJx337003657 for ; Sat, 21 Aug 2004 21:59:03 +0200 (CEST) (envelope-from hampi@rootshell.be) Received: (from idefix@localhost) by localhost.here (8.12.8p2/8.12.8/Submit) id i7LJx3SX003656 for freebsd-acpi@freebsd.org; Sat, 21 Aug 2004 21:59:03 +0200 (CEST) X-Authentication-Warning: localhost.here: idefix set sender to hampi@rootshell.be using -f Date: Sat, 21 Aug 2004 21:59:03 +0200 From: Hanspeter Roth To: freebsd-acpi@freebsd.org Message-ID: <20040821195903.GA3578@gicco.homeip.net> Mail-Followup-To: freebsd-acpi@freebsd.org References: <20040814163010.GA851@gicco.homeip.net> <4122A173.6030100@root.org> <20040820231227.GA3956@gicco.homeip.net> <4127957B.2050000@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4127957B.2050000@root.org> User-Agent: Mutt/1.4.1i Subject: Re: suspend on Pavilion hangs 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, 21 Aug 2004 19:59:07 -0000 On Aug 21 at 11:33, Nate Lawson spoke: > Hanspeter Roth wrote: > > > >acpi_lid0: wake_prep enabled for \_SB_.C136 (S3) [...] > > That message is totally normal and just means that your lid switch is > being enabled to _wake_ the system. So if you suspend with 'zzz' or > whatever, you can still wake via the lid. This can be disabled via a > sysctl if you want. I have now played with `acpiconf -s 4'. This displays several `something: wake_prep disabled wake for \_SB_.C046.xxx (S4)' I guess this means that the respective devices cannot wake the laptop from S4. (But the powerbutton only.) > of laptops including on Linux. The process for fixing it is simple: > begin by auditing all device drivers and fixing their suspend/resume > methods. Continue on to fix all X video drivers by getting the Is there a good sample of a driver where suspend/resume is known to work? -Hanspeter