From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 11 14:46:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B9E616A4CE for ; Sun, 11 Apr 2004 14:46:04 -0700 (PDT) Received: from cube.webcom.it (cube.webcom.it [194.185.205.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10B4143D1D for ; Sun, 11 Apr 2004 14:46:04 -0700 (PDT) (envelope-from andrea@webcom.it) Received: by cube.webcom.it (Postfix, from userid 501) id EF714B17B9; Sun, 11 Apr 2004 23:46:01 +0200 (CEST) Date: Sun, 11 Apr 2004 23:46:01 +0200 From: Andrea Campi To: freebsd-acpi@freebsd.org Message-ID: <20040411214601.GB10610@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: failed to deactivate \_TZ_.FAN_ 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, 11 Apr 2004 21:46:04 -0000 Hi, I just updated my laptop (ThinkPad 570E) past the latest changes in PCI and ACPI (from April 6 to April 11), and everything is still working fine, devices are powered up etc. The fan is working fine; however, whenever it turns on I get the message in the subject. I guess there's nothing to worry about, but maybe Nate could be interested (here I'm assuming the change to get reference is somehow related). My asl is in the archives, or I could just resend it. Bye, Andrea -- There's no place like ~ From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 11 20:01:05 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 ABD0D16A4CE for ; Sun, 11 Apr 2004 20:01:05 -0700 (PDT) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D86B43D48 for ; Sun, 11 Apr 2004 20:01:05 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from kiki.cs.rpi.edu (kiki.cs.rpi.edu [128.213.50.12]) i3C314lE082515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Apr 2004 23:01:04 -0400 (EDT) Received: from kiki.cs.rpi.edu (localhost [127.0.0.1]) by kiki.cs.rpi.edu (8.12.9/8.12.6) with ESMTP id i3C3134F020833 for ; Sun, 11 Apr 2004 23:01:03 -0400 (EDT) (envelope-from crossd@kiki.cs.rpi.edu) Received: from localhost (crossd@localhost) by kiki.cs.rpi.edu (8.12.9/8.12.6/Submit) with ESMTP id i3C312aT020830 for ; Sun, 11 Apr 2004 23:01:03 -0400 (EDT) (envelope-from crossd@kiki.cs.rpi.edu) Date: Sun, 11 Apr 2004 23:01:01 -0400 (EDT) From: "David E. Cross" To: freebsd-acpi@freebsd.org Message-ID: <20040411225543.P20829@kiki.cs.rpi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.37 Subject: System weirdness (followup) 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, 12 Apr 2004 03:01:05 -0000 Ok, since I put the hint.apic.0.disabled=1 in loader.conf I have been noticing weirdness on my system, programs will randomly bus-error on startup (I have noticed it with grep, dd, and md5). It appears to only be on startup, and only the first time I run the program (when it needs to get it from disk). Dmesg shows no errors (read errors, swap errors, etc), and I doubt hardware because 1) It just started doing this 2) I have ECC everything 3) it is always bus-error (not seg fault, ILL, or other things that traditionally indicate hardware/memory issues, and 4) its only at program initialization. Is it possible that turning of the IOAPIC caused some sort of issue or race withing the system? It really looks like the error is a page is attempted to be executed before its pinned; (like a fault occurs on one CPU, and then the process is switched to the other before its pulled in, and "boom" -- David E. Cross From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 11 22:06:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49DEC16A4CE for ; Sun, 11 Apr 2004 22:06:04 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D39443D3F for ; Sun, 11 Apr 2004 22:06:04 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 66528 invoked by uid 1000); 12 Apr 2004 05:06:06 -0000 Date: Sun, 11 Apr 2004 22:06:06 -0700 (PDT) From: Nate Lawson To: Andrea Campi In-Reply-To: <20040411214601.GB10610@webcom.it> Message-ID: <20040411220211.M66438@root.org> References: <20040411214601.GB10610@webcom.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-acpi@freebsd.org Subject: Re: failed to deactivate \_TZ_.FAN_ 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, 12 Apr 2004 05:06:04 -0000 On Sun, 11 Apr 2004, Andrea Campi wrote: > I just updated my laptop (ThinkPad 570E) past the latest changes in PCI > and ACPI (from April 6 to April 11), and everything is still working > fine, devices are powered up etc. > > The fan is working fine; however, whenever it turns on I get the message > in the subject. I guess there's nothing to worry about, but maybe Nate > could be interested (here I'm assuming the change to get reference is > somehow related). My asl is in the archives, or I could just resend it. The commit added an error check for this case but the case is that the fan is usually already off, so it was overly verbose in reporting this. I removed the message. There was no problem with the code, only excessive messages. -Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Apr 12 17:38:43 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 AC10216A4CF for ; Mon, 12 Apr 2004 17:38:43 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D65243D1F for ; Mon, 12 Apr 2004 17:38:43 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 71674 invoked by uid 1000); 13 Apr 2004 00:38:45 -0000 Date: Mon, 12 Apr 2004 17:38:45 -0700 (PDT) From: Nate Lawson To: acpi-devel@lists.sourceforge.net Message-ID: <20040412172333.Y71599@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Device power for suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2004 00:38:43 -0000 I'm soliciting some comments on proper steps to take with device power on the suspend/resume path. There are some complications like _SxD and none of us support them yet. Here are the abbreviated steps as I see them (only device power code, not general sleep steps): 1. All devices put in power state inferred by power resource ... except if _SxD exists, put them in that state instead ... except if enabling for wake, put in state in _PRW 2. Turn off all power resources no longer referenced 3. Enable wake for all devices that have _PRW [suspend/resume] 4. Turn on all power resources 5. Turn on all devices 6. Run _S0D on devices and put them in the corresponding power state 7. Turn off devices previously off before suspend 8. Turn off all power resources no longer referenced While examining how to implement this, I ran into some confusing questions. A. _S0D is not referenced in the spec but it appears some ASL uses this for docking connectors. It returns 3 for when a bus isn't connected to anything (undocked) and 0 when it is present. I'm guessing this should be run on resume after everything is running to see if we can power down a device that is not available (step 7 above). B. The requirement to turn on power resources referenced in _PRW appears to be the overriding factor in the suspend path. That's why I do it last above. C. It's not clear how _SxD overrides the power resource Sx value since a device can't be in a higher state than its power resource. This appears to be a minor issue since most devices that have _SxD that is higher than the desired sleep state do not have a power resource. D. If a device has _PSx methods but no power resource, should it be put in a state equal to its Sx state unless there is an overriding _SxD? For example, all devices should be put in D3 for S3, then power off unreferenced power resources. What if you're going to S1 but there's no _PS1? Leave it in _PS0 unless there is an _S1D saying otherwise? One other issue: there's a bug in hwsleep.c where we don't clear WAK_STS in the S5 path. That should be changed. Comments will help everyone get suspend/resume working better since it appears devices in the wrong power states affect stability here. Thanks, -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 14:34:02 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 4718916A4CE; Tue, 13 Apr 2004 14:34:02 -0700 (PDT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35BB843D4C; Tue, 13 Apr 2004 14:34:02 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Tue, 13 Apr 2004 14:34:01 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 90FE15D08; Tue, 13 Apr 2004 14:34:01 -0700 (PDT) To: imp@impbsd.net Date: Tue, 13 Apr 2004 14:34:01 -0700 From: "Kevin Oberman" Message-Id: <20040413213401.90FE15D08@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Experiences with new PCI code 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, 13 Apr 2004 21:34:02 -0000 System: IBM T30 (ICH3, 1.8G P4-M, 512 MB RAM, Intel/Xircom Pro/100 VE Ethernet, TI1520 CardBus bridge, Prism 2.5 wireless, Analog Devices AD1881A AC97 codec) After the integration of the new PCI code the suspend/resume behavior is very different than before. Suspend: - Display backlight still turns on and remains on upon suspend. Video does not blank, but loses power so display "rots" over a period of at least minutes. (This is unchanged.) hw.acpi.video show correct values, but fails to change them. DPMS blanking does blank the display but does not turn off back-light. - hw.acpi.sleep_delay is now ignored, but the disk no longer does an instant shutdown without flushing cache, so this is OK. - Suspend LED turns on. (Unchanged.) Resume: - I stop receiving interrupts on irq11 which handles much of my system. This includes sound, CardBus, USB and network. This is the big issue as the machine is now pretty useless. Unfortunately, this loss of irq11 makes further testing almost impossible. To further confuse things, interrupts continue for a seemingly random time of up to several minutes after the restore and then stop. This last part has me totally baffled, but maybe someone has some idea why this is happening. Non-irq11 devices (mouse, keyboard, clocks, ata controllers) continue to work. Anything you would like me to try? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 14:41: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 C7F2516A4CE for ; Tue, 13 Apr 2004 14:41:12 -0700 (PDT) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 087AC43D41 for ; Tue, 13 Apr 2004 14:41:12 -0700 (PDT) (envelope-from jason@ec.rr.com) Received: from ec.rr.com (cpe-024-211-231-149.ec.rr.com [24.211.231.149]) i3DLf9Sm026465 for ; Tue, 13 Apr 2004 17:41:10 -0400 (EDT) Message-ID: <407C5F2E.2090802@ec.rr.com> Date: Tue, 13 Apr 2004 17:44:14 -0400 From: jason User-Agent: Mozilla Thunderbird 0.5 (X11/20040330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: nforce progress 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, 13 Apr 2004 21:41:12 -0000 I just subscribed and would like to know how things are progressing. If you need help I've already done little on my nforce2, since last I heard acpi is broken on nforce stuff. I have not fixed the acpi stuff yet on my board and if any one is interested I will put all the acpi stuff I have up on my site for you to browse, or email it. I have an acpidump and all the tables. When I decompile there is at least 1 error I remember, and a couple of different ones when I try to recompile with no changes. Also if it matters the mptable on my epox nforce is hosed and epox basicly told me "we don't support Linux" when I did not even use the word linux in my emails. A ms only company I guess? I can post that to if you want it. Let me know if anyone has the time to look over my stuff. Thx, Jason From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 15:01:45 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 571D516A4CE; Tue, 13 Apr 2004 15:01:45 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02EF543D45; Tue, 13 Apr 2004 15:01:43 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Tue, 13 Apr 2004 15:01:42 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5F50E5D08; Tue, 13 Apr 2004 15:01:42 -0700 (PDT) To: imp@bsdimp.com Date: Tue, 13 Apr 2004 15:01:42 -0700 From: "Kevin Oberman" Message-Id: <20040413220142.5F50E5D08@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Experiences with new PCI code 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, 13 Apr 2004 22:01:45 -0000 System: IBM T30 (ICH3, 1.8G P4-M, 512 MB RAM, Intel/Xircom Pro/100 VE Ethernet, TI1520 CardBus bridge, Prism 2.5 wireless, Analog Devices AD1881A AC97 codec) After the integration of the new PCI code the suspend/resume behavior is very different than before. Unfortunately, it's worse, but moving in the right direction. Suspend: - Display backlight still turns on and remains on upon suspend. Video does not blank, but loses power so display "rots" over a period of at least minutes. (This is unchanged.) hw.acpi.video show correct values, but fails to change them. DPMS blanking does blank the display but does not turn off back-light. - hw.acpi.sleep_delay is now ignored, but the disk no longer does an instant shutdown without flushing cache, so this is OK. - Suspend LED turns on. (Unchanged.) Resume: - I stop receiving interrupts on irq11 which handles much of my system. This includes sound, CardBus, USB and network. This is the big issue as the machine is now pretty useless. Unfortunately, this loss of irq11 makes further testing almost impossible. To further confuse things, interrupts continue for a seemingly random time of up to several minutes after the restore and then stop. This last part has me totally baffled, but maybe someone has some idea why this is happening. Non-irq11 devices (mouse, keyboard, clocks, ata controllers) continue to work. Anything you would like me to try? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 19:27:30 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F133716A4CE; Tue, 13 Apr 2004 19:27:29 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F4043D2F; Tue, 13 Apr 2004 19:27:29 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i3E2RPkj014870; Tue, 13 Apr 2004 20:27:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 13 Apr 2004 20:28:17 -0600 (MDT) Message-Id: <20040413.202817.35014248.imp@bsdimp.com> To: oberman@es.net From: "M. Warner Losh" In-Reply-To: <20040413220142.5F50E5D08@ptavv.es.net> References: <20040413220142.5F50E5D08@ptavv.es.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 02:27:30 -0000 In message: <20040413220142.5F50E5D08@ptavv.es.net> "Kevin Oberman" writes: : System: IBM T30 (ICH3, 1.8G P4-M, 512 MB RAM, Intel/Xircom Pro/100 VE : Ethernet, TI1520 CardBus bridge, Prism 2.5 wireless, Analog Devices : AD1881A AC97 codec) : : After the integration of the new PCI code the suspend/resume behavior is : very different than before. Unfortunately, it's worse, but moving in the : right direction. : : Suspend: : - Display backlight still turns on and remains on upon suspend. Video : does not blank, but loses power so display "rots" over a period of at : least minutes. (This is unchanged.) hw.acpi.video show correct values, : but fails to change them. DPMS blanking does blank the display but : does not turn off back-light. : : - hw.acpi.sleep_delay is now ignored, but the disk no longer does an : instant shutdown without flushing cache, so this is OK. : : - Suspend LED turns on. (Unchanged.) : : Resume: : - I stop receiving interrupts on irq11 which handles much of my : system. This includes sound, CardBus, USB and network. This is the : big issue as the machine is now pretty useless. : : Unfortunately, this loss of irq11 makes further testing almost : impossible. To further confuse things, interrupts continue for a : seemingly random time of up to several minutes after the restore and : then stop. This last part has me totally baffled, but maybe someone has : some idea why this is happening. Non-irq11 devices (mouse, keyboard, : clocks, ata controllers) continue to work. : : Anything you would like me to try? While my patches will make it better, more extensive changes to the power code will be necessary to make it work perfectly. Nate has been taking the lead in this area. Why don't you try hw.pci.do_powerstates=1 to see if that helps any. This will turn on more power managmenet code. Warner From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 21:23: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 B924916A4CF for ; Tue, 13 Apr 2004 21:23:37 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9E77243D5C for ; Tue, 13 Apr 2004 21:23:37 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 79791 invoked by uid 1000); 14 Apr 2004 04:23:39 -0000 Date: Tue, 13 Apr 2004 21:23:39 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040413.202817.35014248.imp@bsdimp.com> Message-ID: <20040413212208.C79433@root.org> References: <20040413220142.5F50E5D08@ptavv.es.net> <20040413.202817.35014248.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 04:23:37 -0000 On Tue, 13 Apr 2004, M. Warner Losh wrote: > In message: <20040413220142.5F50E5D08@ptavv.es.net> > "Kevin Oberman" writes: > : System: IBM T30 (ICH3, 1.8G P4-M, 512 MB RAM, Intel/Xircom Pro/100 VE > : Ethernet, TI1520 CardBus bridge, Prism 2.5 wireless, Analog Devices > : AD1881A AC97 codec) > : > : After the integration of the new PCI code the suspend/resume behavior is > : very different than before. Unfortunately, it's worse, but moving in the > : right direction. > : > : Suspend: > : - Display backlight still turns on and remains on upon suspend. Video > : does not blank, but loses power so display "rots" over a period of at > : least minutes. (This is unchanged.) hw.acpi.video show correct values, > : but fails to change them. DPMS blanking does blank the display but > : does not turn off back-light. > : > : - hw.acpi.sleep_delay is now ignored, but the disk no longer does an > : instant shutdown without flushing cache, so this is OK. > : > : - Suspend LED turns on. (Unchanged.) > : > : Resume: > : - I stop receiving interrupts on irq11 which handles much of my > : system. This includes sound, CardBus, USB and network. This is the > : big issue as the machine is now pretty useless. > : > : Unfortunately, this loss of irq11 makes further testing almost > : impossible. To further confuse things, interrupts continue for a > : seemingly random time of up to several minutes after the restore and > : then stop. This last part has me totally baffled, but maybe someone has > : some idea why this is happening. Non-irq11 devices (mouse, keyboard, > : clocks, ata controllers) continue to work. > : > : Anything you would like me to try? > > While my patches will make it better, more extensive changes to the > power code will be necessary to make it work perfectly. Nate has been > taking the lead in this area. > > Why don't you try > > hw.pci.do_powerstates=1 > > to see if that helps any. This will turn on more power managmenet > code. That's a good thing to do. In the suspend/resume path, I'm working on a plan for supporting _SxD and various methods to set the 'right' power state going into suspend and coming out of resume. It's not easy. The other major issue that I can't ever solve is drivers not correctly resuming themselves. That is up to the driver authors and a lot are incomplete. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 22:12: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 582F916A4CE; Tue, 13 Apr 2004 22:12:12 -0700 (PDT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id C76FC43D45; Tue, 13 Apr 2004 22:12:11 -0700 (PDT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i3E5C7v6080758; Wed, 14 Apr 2004 07:12:07 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i3E5C7lW080757; Wed, 14 Apr 2004 07:12:07 +0200 (CEST) (envelope-from stijn) Date: Wed, 14 Apr 2004 07:12:07 +0200 From: Stijn Hoop To: Nate Lawson Message-ID: <20040414051207.GK58667@pcwin002.win.tue.nl> References: <20040413220142.5F50E5D08@ptavv.es.net> <20040413.202817.35014248.imp@bsdimp.com> <20040413212208.C79433@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I3tAPq1Rm2pUxvsp" Content-Disposition: inline In-Reply-To: <20040413212208.C79433@root.org> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 05:12:12 -0000 --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2004 at 09:23:39PM -0700, Nate Lawson wrote: > The other major issue that I can't ever solve is drivers not correctly > resuming themselves. That is up to the driver authors and a lot are > incomplete. Is there a list somewhere so that we end users don't report lots of known problems? --Stijn --=20 I wish there was a knob on the TV to turn up the intelligence. There's a k= nob called `brightness', but it doesn't work." -- Gallagher --I3tAPq1Rm2pUxvsp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAfMgnY3r/tLQmfWcRAoUtAJ9tuovPIzNWClbrL+jQHBQ1Jzo43QCdFv0j mkITtu99euPYoNHSWdmsNKk= =yFDD -----END PGP SIGNATURE----- --I3tAPq1Rm2pUxvsp-- From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 22:27:45 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 39A9816A4CE for ; Tue, 13 Apr 2004 22:27:45 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E097F43D39 for ; Tue, 13 Apr 2004 22:27:44 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 80196 invoked by uid 1000); 14 Apr 2004 05:27:46 -0000 Date: Tue, 13 Apr 2004 22:27:46 -0700 (PDT) From: Nate Lawson To: Stijn Hoop In-Reply-To: <20040414051207.GK58667@pcwin002.win.tue.nl> Message-ID: <20040413222717.O80191@root.org> References: <20040413220142.5F50E5D08@ptavv.es.net> <20040413.202817.35014248.imp@bsdimp.com> <20040414051207.GK58667@pcwin002.win.tue.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 05:27:45 -0000 On Wed, 14 Apr 2004, Stijn Hoop wrote: > On Tue, Apr 13, 2004 at 09:23:39PM -0700, Nate Lawson wrote: > > The other major issue that I can't ever solve is drivers not correctly > > resuming themselves. That is up to the driver authors and a lot are > > incomplete. > > Is there a list somewhere so that we end users don't report lots of > known problems? That's item one on the list: make a list. Care to start one? :) -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 22:41: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 E2D5616A4CE; Tue, 13 Apr 2004 22:41:56 -0700 (PDT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5813D43D3F; Tue, 13 Apr 2004 22:41:56 -0700 (PDT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.11/8.12.11) with ESMTP id i3E5fr46080976; Wed, 14 Apr 2004 07:41:53 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.11/8.12.11/Submit) id i3E5fr6a080975; Wed, 14 Apr 2004 07:41:53 +0200 (CEST) (envelope-from stijn) Date: Wed, 14 Apr 2004 07:41:52 +0200 From: Stijn Hoop To: Nate Lawson Message-ID: <20040414054152.GL58667@pcwin002.win.tue.nl> References: <20040413220142.5F50E5D08@ptavv.es.net> <20040413.202817.35014248.imp@bsdimp.com> <20040413212208.C79433@root.org> <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qVHblb/y9DPlgkHs" Content-Disposition: inline In-Reply-To: <20040413222717.O80191@root.org> User-Agent: Mutt/1.4.2.1i X-Bright-Idea: Let's abolish HTML mail! cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 05:41:57 -0000 --qVHblb/y9DPlgkHs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 13, 2004 at 10:27:46PM -0700, Nate Lawson wrote: > On Wed, 14 Apr 2004, Stijn Hoop wrote: > > On Tue, Apr 13, 2004 at 09:23:39PM -0700, Nate Lawson wrote: > > > The other major issue that I can't ever solve is drivers not correctly > > > resuming themselves. That is up to the driver authors and a lot are > > > incomplete. > > > > Is there a list somewhere so that we end users don't report lots of > > known problems? >=20 > That's item one on the list: make a list. Care to start one? :) Errrr... Can I tell by reading / grepping the source? --Stijn --=20 "Harry, I'm going to let you in on a little secret. Every day, once a day, give yourself a present. Don't plan it, don't wait for it, just let it happen. Could be a new shirt at the men's store, a catnap in your office chair, or... two cups of good, hot, black coffee. Like this." -- Special Agent Dale Cooper, "Twin Peaks" --qVHblb/y9DPlgkHs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAfM8gY3r/tLQmfWcRAstWAJ4uDtBO3J6aZcUzaJzBS4N1b+sLjgCeN981 mJkcZaoy2hgWFBy8qlTn2mo= =9v50 -----END PGP SIGNATURE----- --qVHblb/y9DPlgkHs-- From owner-freebsd-acpi@FreeBSD.ORG Tue Apr 13 23:09:46 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C229416A4CE; Tue, 13 Apr 2004 23:09:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5637B43D3F; Tue, 13 Apr 2004 23:09:46 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i3E69jkj017603; Wed, 14 Apr 2004 00:09:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Apr 2004 00:10:39 -0600 (MDT) Message-Id: <20040414.001039.116586661.imp@bsdimp.com> To: stijn@win.tue.nl From: "M. Warner Losh" In-Reply-To: <20040414054152.GL58667@pcwin002.win.tue.nl> References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org> <20040414054152.GL58667@pcwin002.win.tue.nl> 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: Experiences with new PCI code 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, 14 Apr 2004 06:09:46 -0000 In message: <20040414054152.GL58667@pcwin002.win.tue.nl> Stijn Hoop writes: : On Tue, Apr 13, 2004 at 10:27:46PM -0700, Nate Lawson wrote: : > On Wed, 14 Apr 2004, Stijn Hoop wrote: : > > On Tue, Apr 13, 2004 at 09:23:39PM -0700, Nate Lawson wrote: : > > > The other major issue that I can't ever solve is drivers not correctly : > > > resuming themselves. That is up to the driver authors and a lot are : > > > incomplete. : > > : > > Is there a list somewhere so that we end users don't report lots of : > > known problems? : > : > That's item one on the list: make a list. Care to start one? :) : : Errrr... Can I tell by reading / grepping the source? Typically no. You tell because on your otherwise working laptop, the Foo device doesn't resume. Warner From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 14 09:29: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 AC89016A4CF for ; Wed, 14 Apr 2004 09:29:36 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7072F43D53 for ; Wed, 14 Apr 2004 09:29:34 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 83516 invoked by uid 1000); 14 Apr 2004 16:29:35 -0000 Date: Wed, 14 Apr 2004 09:29:35 -0700 (PDT) From: Nate Lawson To: stijn@win.tue.nl In-Reply-To: <20040414.001039.116586661.imp@bsdimp.com> Message-ID: <20040414092553.F83452@root.org> References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org> <20040414.001039.116586661.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 16:29:36 -0000 On Wed, 14 Apr 2004, M. Warner Losh wrote: > In message: <20040414054152.GL58667@pcwin002.win.tue.nl> > Stijn Hoop writes: > : On Tue, Apr 13, 2004 at 10:27:46PM -0700, Nate Lawson wrote: > : > On Wed, 14 Apr 2004, Stijn Hoop wrote: > : > > On Tue, Apr 13, 2004 at 09:23:39PM -0700, Nate Lawson wrote: > : > > > The other major issue that I can't ever solve is drivers not correctly > : > > > resuming themselves. That is up to the driver authors and a lot are > : > > > incomplete. > : > > > : > > Is there a list somewhere so that we end users don't report lots of > : > > known problems? > : > > : > That's item one on the list: make a list. Care to start one? :) > : > : Errrr... Can I tell by reading / grepping the source? > > Typically no. You tell because on your otherwise working laptop, the > Foo device doesn't resume. Yep. You can grep for drivers that don't have device_suspend in their methods list. But most have one. The usual case is that the suspend method is incomplete for some chipsets although it works ok on others. For instance, snd_ich works pretty well for me but will stop generating interrupts if shared with if_an on resume. But for others its sample rate is off after resume. Now this problem may have been fixed by Warner's power code so it would be a good time to test those drivers because if the problem is still there, it's a driver problem and there's not much more to be done outside the driver. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 14 10:42: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 89DDF16A4CE; Wed, 14 Apr 2004 10:42:42 -0700 (PDT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 675F943D53; Wed, 14 Apr 2004 10:42:42 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 14 Apr 2004 10:42:41 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 87EA45D07; Wed, 14 Apr 2004 10:42:41 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Tue, 13 Apr 2004 21:23:39 PDT." <20040413212208.C79433@root.org> Date: Wed, 14 Apr 2004 10:42:41 -0700 From: "Kevin Oberman" Message-Id: <20040414174241.87EA45D07@ptavv.es.net> cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 17:42:42 -0000 > Date: Tue, 13 Apr 2004 21:23:39 -0700 (PDT) > From: Nate Lawson > > On Tue, 13 Apr 2004, M. Warner Losh wrote: > > In message: <20040413220142.5F50E5D08@ptavv.es.net> > > "Kevin Oberman" writes: > > : System: IBM T30 (ICH3, 1.8G P4-M, 512 MB RAM, Intel/Xircom Pro/100 VE > > : Ethernet, TI1520 CardBus bridge, Prism 2.5 wireless, Analog Devices > > : AD1881A AC97 codec) > > : > > : After the integration of the new PCI code the suspend/resume behavior is > > : very different than before. Unfortunately, it's worse, but moving in the > > : right direction. > > : > > : Suspend: > > : - Display backlight still turns on and remains on upon suspend. Video > > : does not blank, but loses power so display "rots" over a period of at > > : least minutes. (This is unchanged.) hw.acpi.video show correct values, > > : but fails to change them. DPMS blanking does blank the display but > > : does not turn off back-light. > > : > > : - hw.acpi.sleep_delay is now ignored, but the disk no longer does an > > : instant shutdown without flushing cache, so this is OK. > > : > > : - Suspend LED turns on. (Unchanged.) > > : > > : Resume: > > : - I stop receiving interrupts on irq11 which handles much of my > > : system. This includes sound, CardBus, USB and network. This is the > > : big issue as the machine is now pretty useless. > > : > > : Unfortunately, this loss of irq11 makes further testing almost > > : impossible. To further confuse things, interrupts continue for a > > : seemingly random time of up to several minutes after the restore and > > : then stop. This last part has me totally baffled, but maybe someone has > > : some idea why this is happening. Non-irq11 devices (mouse, keyboard, > > : clocks, ata controllers) continue to work. > > : > > : Anything you would like me to try? > > > > While my patches will make it better, more extensive changes to the > > power code will be necessary to make it work perfectly. Nate has been > > taking the lead in this area. > > > > Why don't you try > > > > hw.pci.do_powerstates=1 > > It does help (though it's hw.pci.do_powerstate=1). This has fixed the problem of losing irq11. Now I am operational after resume. USB seems to be working (untested). Video is fine. Sound is still not working correctly. It runs at native speed (about 52K) after resume which makes things run a bit fast and breaks playing live streams. Attempts to use the sysctl to set the speed don't work. I already have a PR open on this. Bottom line is that things are a whole lot better. Suspend/resume is usable if not practical. Remaining big problems are the display which won't turn off (and turns back on if already off) and the sound. Sound is important on this system as I use it to participate in H.323 conferences with gnomemeeting. All in all I am very happy with the progress on this. Warner's PCI patches are a huge improvement. The sound problem is probably a driver issue. I plan on building a kernel without sound support and load the modules. I hope that I can unload and load the module after a suspend and get sound working correctly. Yeah, it's a hack, but a livable one. This only leaves the display and I fear that this is an IBM specific issue. I hope that the work Nate is doing will fix it. Leaving the screen on while suspended sort of defeats the purpose. :-( Thanks to both of you for all of your work on this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Wed Apr 14 13:00:04 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C2F216A4CE for ; Wed, 14 Apr 2004 13:00:04 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id C305F43D41 for ; Wed, 14 Apr 2004 13:00:03 -0700 (PDT) (envelope-from vladimir@math.uic.edu) Received: from cat.math.uic.edu (c-67-162-104-112.client.comcast.net[67.162.104.112]) by comcast.net (sccrmhc12) with SMTP id <200404142000020120018ujve>; Wed, 14 Apr 2004 20:00:03 +0000 Received: (qmail 3714 invoked by uid 31415); 14 Apr 2004 20:00:02 -0000 Date: Wed, 14 Apr 2004 15:00:02 -0500 From: Vladimir Egorin To: Kevin Oberman Message-ID: <20040414200002.GA3673@math.uic.edu> References: <20040413212208.C79433@root.org> <20040414174241.87EA45D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040414174241.87EA45D07@ptavv.es.net> User-Agent: Mutt/1.5.6i cc: acpi@freebsd.org Subject: Re: Experiences with new PCI code 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, 14 Apr 2004 20:00:04 -0000 On Wed, Apr 14, 2004 at 10:42:41AM -0700, Kevin Oberman wrote: > Thanks to both of you for all of your work on this. Ditto here. Much appreciated. -- Vladimir From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 15 06:18: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 7325B16A4CE; Thu, 15 Apr 2004 06:18:23 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0287843D2F; Thu, 15 Apr 2004 06:18:22 -0700 (PDT) (envelope-from peter.schuller@infidyne.com) Received: from scode.mine.nu ([213.113.221.56] [213.113.221.56]) by mxfep02.bredband.com with ESMTP id <20040415131821.EDZ20525.mxfep02.bredband.com@scode.mine.nu>; Thu, 15 Apr 2004 15:18:21 +0200 Received: from localhost (localhost [127.0.0.1]) by scode.mine.nu (Postfix) with ESMTP id A753013EC82; Thu, 15 Apr 2004 15:18:33 +0200 (CEST) From: Peter Schuller To: freebsd-current@freebsd.org Date: Thu, 15 Apr 2004 15:18:32 +0200 User-Agent: KMail/1.6 References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040414054152.GL58667@pcwin002.win.tue.nl> <20040414.001039.116586661.imp@bsdimp.com> In-Reply-To: <20040414.001039.116586661.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404151518.32481.peter.schuller@infidyne.com> cc: stijn@win.tue.nl cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 15 Apr 2004 13:18:23 -0000 > : > That's item one on the list: make a list. Care to start one? :) > : > : Errrr... Can I tell by reading / grepping the source? > > Typically no. You tell because on your otherwise working laptop, the > Foo device doesn't resume. A while back I submitted a PR with a patch for the em driver but I don't think anyone's had the time to look at it: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/59806 Perhaps the patch is naive/broken, but it *does* fix the suspend/resume problems on my T40p. If anyone has the time to have a look, perhaps we'd have one driver one step closer to being suspend/resume capable. (Or we'll have determined that I know far too little about this stuff to be submitting patches, but I'll risk it...) -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 15 07:15:35 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 A58CA16A4CE for ; Thu, 15 Apr 2004 07:15:35 -0700 (PDT) Received: from smtp.rdsnet.ro (smtp.rdsnet.ro [62.231.74.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C310443D53 for ; Thu, 15 Apr 2004 07:15:34 -0700 (PDT) (envelope-from itetcu@apropo.ro) Received: (qmail 31436 invoked by uid 89); 15 Apr 2004 14:12:30 -0000 Received: from unknown (HELO rdsnet.ro) (62.231.74.131) by 0 with SMTP; 15 Apr 2004 14:12:30 -0000 Received: (qmail 1468 invoked from network); 15 Apr 2004 14:15:33 -0000 Received: from unknown (HELO buh.cameradicommercio.ro) (81.196.25.19) by mail.rdsnet.ro with SMTP; 15 Apr 2004 14:15:33 -0000 Received: from it.buh.cameradicommercio.ro (it.buh.cameradicommercio.ro [192.168.0.10]) by buh.cameradicommercio.ro (Postfix) with ESMTP id EDF5C60DB for ; Thu, 15 Apr 2004 17:15:20 +0300 (EEST) Received: from localhost (localhost.buh.cameradicommercio.ro [127.0.0.1]) by it.buh.cameradicommercio.ro (Postfix) with ESMTP id EF65126C for ; Thu, 15 Apr 2004 17:18:37 +0300 (EEST) Received: from it.buh.cameradicommercio.ro ([127.0.0.1])port 10024) with ESMTP id 02474-10 for ; Thu, 15 Apr 2004 17:18:37 +0300 (EEST) Received: from it.buh.cameradicommercio.ro (localhost.buh.cameradicommercio.ro [127.0.0.1]) by it.buh.cameradicommercio.ro (Postfix) with SMTP id 9AEB8133 for ; Thu, 15 Apr 2004 17:18:37 +0300 (EEST) Date: Thu, 15 Apr 2004 17:18:37 +0300 From: Ion-Mihai Tetcu To: freebsd-acpi@freebsd.org Message-Id: <20040415171837.6580d1b1@it.buh.cameradicommercio.ro> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at it.buh.cameradicommercio.ro Subject: kernel: rtc: 1000 > kern.hz: Timing will be inaccurate, please increase hz. 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, 15 Apr 2004 14:15:35 -0000 Hi, I've started to get this messages after upgrading to /src/sys/dev/acpica/acpi_pcib.c rev=1.38 from rev 1.36 and recompiling kernel. I've did that because of an incorrect routing that was fixed by Nate in this revision. (See the thread on current@ beginning with: http://docs.freebsd.org/cgi/mid.cgi?20040322192654.2f24ef17 ) For the moment I believed it was because I didn't do a "full" cvsup; but I've cvsup and make world ... on 2004_04_09 and the problem is still here. The old debug info (corresponding to the incorrect routing from the message above): http://www.people.tecnik93.com/~itetcu/acpi/_PRS_invalid_type_7/ The new dmesg -v and sysctl hw.acpi and KERNCONF (KSE_ULE_UP_apic_2004_04_09 file) at: http://www.people.tecnik93.com/~itetcu/acpi/rtc/ CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2040351672 Hz CPU: AMD Athlon(tm) XP 2400+ (2040.35-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400000 Data TLB: 32 entries, fully associative ..........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 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 acpi_cpu0: on acpi0 acpi_button0: on acpi0 ............... procfs registered Timecounter "TSC" frequency 2040351672 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled Thanks, -- IOnut Unregistered ;) FreeBSD "user" From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 15 12:04: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 D65A516A4CE; Thu, 15 Apr 2004 12:04:32 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id D275543D41; Thu, 15 Apr 2004 12:04:31 -0700 (PDT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id E17BB51CA6; Thu, 15 Apr 2004 21:04:28 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A0EAA4FF58; Thu, 15 Apr 2004 21:04:28 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i3FJ4Sc4020766; Thu, 15 Apr 2004 21:04:28 +0200 Received: (nullmailer pid 993 invoked by uid 1001); Thu, 15 Apr 2004 13:57:55 -0000 Date: Thu, 15 Apr 2004 15:57:55 +0200 From: Mark Santcroos To: Nate Lawson Message-ID: <20040415135755.GA925@laptop.6bone.nl> References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org> <20040414.001039.116586661.imp@bsdimp.com> <20040414092553.F83452@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040414092553.F83452@root.org> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.251308 / 0.2 / 0.0 / disabled X-RIPE-Signature: f8e90f28024b2131b934d1635cd330af cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 15 Apr 2004 19:04:33 -0000 On Wed, Apr 14, 2004 at 09:29:35AM -0700, Nate Lawson wrote: > For instance, snd_ich works pretty well for me but will stop generating > interrupts if shared with if_an on resume. But for others its sample rate > is off after resume. Now this problem may have been fixed by Warner's > power code so it would be a good time to test those drivers because if the > problem is still there, it's a driver problem and there's not much more > to be done outside the driver. My laptop was one of those with the snd_ich problems after S4_BIOS resume. It was caused by bad BAR restores as the problem could be fixed by simply setting the PCI registers as they were before suspend. I can acknowledge that it now works without any twiddling. Listening to some music right now after I have just suspended :-) Like said before, the PCI changes didn't have any influence on my "S3 immediate resume after suspend" issue. Mark From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 15 13:36: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 09A2616A4D3 for ; Thu, 15 Apr 2004 13:36:49 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9969443D62 for ; Thu, 15 Apr 2004 13:36:48 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 92290 invoked by uid 1000); 15 Apr 2004 20:36:49 -0000 Date: Thu, 15 Apr 2004 13:36:49 -0700 (PDT) From: Nate Lawson To: Mark Santcroos In-Reply-To: <20040415135755.GA925@laptop.6bone.nl> Message-ID: <20040415133527.G92275@root.org> References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org><20040414092553.F83452@root.org> <20040415135755.GA925@laptop.6bone.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 15 Apr 2004 20:36:49 -0000 On Thu, 15 Apr 2004, Mark Santcroos wrote: > On Wed, Apr 14, 2004 at 09:29:35AM -0700, Nate Lawson wrote: > > For instance, snd_ich works pretty well for me but will stop generating > > interrupts if shared with if_an on resume. But for others its sample rate > > is off after resume. Now this problem may have been fixed by Warner's > > power code so it would be a good time to test those drivers because if the > > problem is still there, it's a driver problem and there's not much more > > to be done outside the driver. > > My laptop was one of those with the snd_ich problems after S4_BIOS resume. > It was caused by bad BAR restores as the problem could be fixed by simply > setting the PCI registers as they were before suspend. > > I can acknowledge that it now works without any twiddling. > Listening to some music right now after I have just suspended :-) > > Like said before, the PCI changes didn't have any influence on my "S3 > immediate resume after suspend" issue. So you're saying your system doesn't stay in S3 but immediately wakes up even with the latest -current? Try commenting out all callers to acpi_enable_wake*(), including in acpi_lid, etc. Perhaps a premature wake event is being triggered. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 15 16:20: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 EBD9016A4CE for ; Thu, 15 Apr 2004 16:20:44 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ABE0643D48 for ; Thu, 15 Apr 2004 16:20:44 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 92892 invoked by uid 1000); 15 Apr 2004 23:20:46 -0000 Date: Thu, 15 Apr 2004 16:20:46 -0700 (PDT) From: Nate Lawson To: Kevin Oberman In-Reply-To: <20040415151325.8888A5D07@ptavv.es.net> Message-ID: <20040415161841.A92883@root.org> References: <20040415151325.8888A5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org Subject: Re: cvs commit: src/sys/contrib/dev/acpica hwsleep.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: Thu, 15 Apr 2004 23:20:45 -0000 [moved to acpi@] On Thu, 15 Apr 2004, Kevin Oberman wrote: > > Date: Wed, 14 Apr 2004 22:42:29 -0700 (PDT) > > From: Nate Lawson > > On Wed, 14 Apr 2004, Kevin Oberman wrote: > > > > Modified files: > > > > sys/contrib/dev/acpica hwsleep.c > > > > Log: > > > > Even though the patch has been submitted to the vendor, this file is off > > > > the vendor branch. Once more, with feeling! > > > > > > Boy, my timing suck of late. I just rebuilt my system to see if > > > unloading and loading the sound driver would fix my > > > sound-too-fast-after-resume problem. To my amazement, using the loadable > > > drivers I no longer had the problem. I did all sorts of testing to try > > > to figure out why this would make a difference. Then I decided to catch > > > up on cvs-all. > > > > > > Thanks, Nate. This fixes the sound problem on my T30. My only remaining > > > issue is turning off the @#$% back-light! (Not that there might not be > > > other issues I have not hit.) > > > > I can't see how this commit fixes your sound problem. Are you > > loading/unloading the device drivers (i.e. via /etc/rc.suspend,resume)? > > I could see that helping. Or is the problem fixed even without doing > > that? > > It is fixed WITHOUT doing that. > > I built a new kernel without "device pcm" and manually loaded the > driver. I then suspended and resumed. Prior to you last round of > updates (and one patch from Warner that did not appear to be related to > this), the sound would work after the system resumed, but would run at > about 52K, it's raw speed, rather than at the desired 48K. > > Now the sound works fine after a resume. > > Unfortunately, after I sent this message and over an hour after the > system had been resumed, irq11 failed again. All devices using irq11 > simply stopped working including the network and sound devices. This > delay completely baffles me. I can see why there might be interrupt > issues after a resume, but I can't imagine why interrupts would work for > an hour and then fail. > > And only irq11. All other interrupts are fine. That does kind of make > sense as that irq is the one shared by multiple devices. Please send output of vmstat -i after a resume (but before the hang, obviously). > I also now see that if I either load the driver at boot time (from > loader.conf) or build it into the kernel, the driver fails to > attach. The probe returns "(no driver attached)". I think this is > attributable to Warner's last PCI patch. Perhaps that is responsible for > the change in the sound behavior, as well. (Noto Bene! When I say his last > patch, I refer to the one late yesterday morning. I have not cvsuped > today and have not checked out either current@ or cvs-all@, so things > may have changed by now.) Things have likely not changed. This does sound like a resource issue. Output from dmesg with it loaded at boot time and then loaded later would help. -Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 16 00:01: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 5CEB316A4CE; Fri, 16 Apr 2004 00:01:53 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA7443D54; Fri, 16 Apr 2004 00:01:52 -0700 (PDT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id 265048DDB5; Fri, 16 Apr 2004 09:01:52 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D7BE08DDAB; Fri, 16 Apr 2004 09:01:51 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i3G71pc4002376; Fri, 16 Apr 2004 09:01:51 +0200 Received: (nullmailer pid 812 invoked by uid 1001); Fri, 16 Apr 2004 06:12:50 -0000 Date: Fri, 16 Apr 2004 08:12:50 +0200 From: Mark Santcroos To: Nate Lawson Message-ID: <20040416061250.GA792@laptop.6bone.nl> References: <20040414051207.GK58667@pcwin002.win.tue.nl> <20040413222717.O80191@root.org> <20040414.001039.116586661.imp@bsdimp.com> <20040414092553.F83452@root.org> <20040415135755.GA925@laptop.6bone.nl> <20040415133527.G92275@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040415133527.G92275@root.org> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: U 0.252862 / 0.0 / 0.0 / disabled X-RIPE-Signature: c3480b852bd58d4c331072819e2f68ef cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: Experiences with new PCI code 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, 16 Apr 2004 07:01:53 -0000 On Thu, Apr 15, 2004 at 01:36:49PM -0700, Nate Lawson wrote: > So you're saying your system doesn't stay in S3 but immediately wakes up > even with the latest -current? Yes. > Try commenting out all callers to acpi_enable_wake*(), including in > acpi_lid, etc. Perhaps a premature wake event is being triggered. Had tried that before, just to be sure, I did it again now. There are actually only two instances: acpi_lid and acpi_button. I disabled the calls to acpi_device_enable_wake_event() from the _suspend() functions. No luck ... Mark From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 16 08:38: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 90CFB16A4CE for ; Fri, 16 Apr 2004 08:38:17 -0700 (PDT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7150B43D2D for ; Fri, 16 Apr 2004 08:38:17 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Fri, 16 Apr 2004 08:38:16 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id A0C685D07; Fri, 16 Apr 2004 08:38:15 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Thu, 15 Apr 2004 16:20:46 PDT." <20040415161841.A92883@root.org> Date: Fri, 16 Apr 2004 08:38:15 -0700 From: "Kevin Oberman" Message-Id: <20040416153815.A0C685D07@ptavv.es.net> cc: acpi@freebsd.org Subject: Re: cvs commit: src/sys/contrib/dev/acpica hwsleep.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: Fri, 16 Apr 2004 15:38:17 -0000 > Date: Thu, 15 Apr 2004 16:20:46 -0700 (PDT) > From: Nate Lawson > > [moved to acpi@] Sorry. I should have moved my reply here. Thanks for moving it where it belongs. > On Thu, 15 Apr 2004, Kevin Oberman wrote: > > > Date: Wed, 14 Apr 2004 22:42:29 -0700 (PDT) > > > From: Nate Lawson > > > On Wed, 14 Apr 2004, Kevin Oberman wrote: > > > > > Modified files: > > > > > sys/contrib/dev/acpica hwsleep.c > > > > > Log: > > > > > Even though the patch has been submitted to the vendor, this file is off > > > > > the vendor branch. Once more, with feeling! > > > > > > > > Boy, my timing suck of late. I just rebuilt my system to see if > > > > unloading and loading the sound driver would fix my > > > > sound-too-fast-after-resume problem. To my amazement, using the loadable > > > > drivers I no longer had the problem. I did all sorts of testing to try > > > > to figure out why this would make a difference. Then I decided to catch > > > > up on cvs-all. > > > > > > > > Thanks, Nate. This fixes the sound problem on my T30. My only remaining > > > > issue is turning off the @#$% back-light! (Not that there might not be > > > > other issues I have not hit.) > > > > > > I can't see how this commit fixes your sound problem. Are you > > > loading/unloading the device drivers (i.e. via /etc/rc.suspend,resume)? > > > I could see that helping. Or is the problem fixed even without doing > > > that? > > > > It is fixed WITHOUT doing that. > > > > I built a new kernel without "device pcm" and manually loaded the > > driver. I then suspended and resumed. Prior to you last round of > > updates (and one patch from Warner that did not appear to be related to > > this), the sound would work after the system resumed, but would run at > > about 52K, it's raw speed, rather than at the desired 48K. > > > > Now the sound works fine after a resume. > > > > Unfortunately, after I sent this message and over an hour after the > > system had been resumed, irq11 failed again. All devices using irq11 > > simply stopped working including the network and sound devices. This > > delay completely baffles me. I can see why there might be interrupt > > issues after a resume, but I can't imagine why interrupts would work for > > an hour and then fail. > > > > And only irq11. All other interrupts are fine. That does kind of make > > sense as that irq is the one shared by multiple devices. > > Please send output of vmstat -i after a resume (but before the hang, > obviously). I'm unsure why you add "obviously". It's only irq11 that fails. The system remains up and runs fine (except for the relevant devices). vmstat -i after the irq11 failure simply shows the count for irq11 as unchanging. That's how I determined that irq11 had died. Here is a vmstat at the moment. The system has been suspended and resumed. Everything working. Audio playing (so I can know immediately when it fails). The audio makes the rate rather high. It's normally around 2 or 3. Other interrupts look about like I'd expect. interrupt total rate irq0: clk 258992 99 irq1: atkbd0 1556 0 irq8: rtc 331508 127 irq9: acpi0 2389 0 irq11: pcm0 cbb0+++ 78521 30 irq12: psm0 14732 5 irq13: npx0 1 0 irq14: ata0 15421 5 irq15: ata1 72 0 Total 703192 271 > > I also now see that if I either load the driver at boot time (from > > loader.conf) or build it into the kernel, the driver fails to > > attach. The probe returns "(no driver attached)". I think this is > > attributable to Warner's last PCI patch. Perhaps that is responsible for > > the change in the sound behavior, as well. (Noto Bene! When I say his last > > patch, I refer to the one late yesterday morning. I have not cvsuped > > today and have not checked out either current@ or cvs-all@, so things > > may have changed by now.) > > Things have likely not changed. This does sound like a resource issue. > Output from dmesg with it loaded at boot time and then loaded later would > help. They are attached. The dmesg-with-pcm is with snd_pcm and snd_ich loaded at boot time. Sound does not work. (I just realized that the "(no driver attached)" message is actually from the pci driver and is for the WinModem and not part of the problem.) The dmesg-no-pcm is a boot without the drivers loaded. I then added snd_pcm (which produced no messages) and snd_ich. Very different from the probe in the first file! Then I suspended and resumed. And now I am waiting for it to fail. Before I set hw.pci.do_powerstate to 1, the failure was almost immediate. I don't think it ever lasted more than 5 minutes. With do_powerstates I have had only a single failure. That one was over an hour after the resume. So I have no idea when (if?) it will fail this time. When it has failed, is there anything you would like me to do? Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 16 08:40:29 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 DCAD516A4CE for ; Fri, 16 Apr 2004 08:40:29 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2AAC43D49 for ; Fri, 16 Apr 2004 08:40:29 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Fri, 16 Apr 2004 08:40:28 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 992765D08; Fri, 16 Apr 2004 08:40:28 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Nate Lawson In-reply-to: Your message of "Thu, 15 Apr 2004 16:20:46 PDT." <20040415161841.A92883@root.org> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-8274555880" Date: Fri, 16 Apr 2004 08:40:28 -0700 From: "Kevin Oberman" Message-Id: <20040416154028.992765D08@ptavv.es.net> cc: acpi@freebsd.org Subject: Re: cvs commit: src/sys/contrib/dev/acpica hwsleep.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: Fri, 16 Apr 2004 15:40:30 -0000 This is a multipart MIME message. --==_Exmh_-8274555880 Content-Type: text/plain; charset=us-ascii [Obscenity deleted] I forgot to attach the files. Here they are. Sorry. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 --==_Exmh_-8274555880 Content-Type: text/plain ; name="dmesg-no-pcm"; charset=us-ascii Content-Description: dmesg-no-pcm Content-Disposition: attachment; filename="dmesg-no-pcm" bios32: Found BIOS32 Service Directory header at 0xc00f6fe0 bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd770+0x18e pnpbios: Found PnP BIOS data at 0xc00f7040 pnpbios: Entry = f0000:9d54 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: mem: Pentium Pro MTRR support enabled null: cpu0 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] acpi_ec0: port 0x66,0x62 on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=1a308086) pcibios: BIOS version 2.10 Found $PIR table, 14 entries at 0xc00fdeb0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 2 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 9 1 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 9 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 9 2 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 8 A 0x68 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 2 dev 0 func 0 AcpiOsDerivePciId: bus 2 dev 0 func 1 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 0: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 ACPI PCI link before setting link priority: \\_SB_.LNKH: interrupts: 3 4 5 6 7 9 10 11 penalty: 1110 1110 110 1110 1110 110 110 610 references: 1 priority: 0 ACPI PCI link before fixup for boot-disabled links: \\_SB_.LNKH: interrupts: 3 4 5 6 7 9 10 11 penalty: 1110 1110 110 1110 1110 110 110 610 references: 1 priority: 672 ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x8086, dev=0x1a30, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1a31, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKA) pcib0: slot 29 INTA is routed to irq 11 found-> vendor=0x8086, dev=0x2482, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 00001820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKD) pcib0: slot 29 INTB is routed to irq 11 found-> vendor=0x8086, dev=0x2484, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type 4, range 32, base 00001840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC) pcib0: slot 29 INTC is routed to irq 11 found-> vendor=0x8086, dev=0x2487, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 found-> vendor=0x8086, dev=0x2448, revid=0x42 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x248c, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 000001f0, size 3, enabled map[14]: type 4, range 32, base 000003f4, size 2, enabled map[18]: type 4, range 32, base 00000170, size 3, enabled map[1c]: type 4, range 32, base 00000374, size 2, enabled map[20]: type 4, range 32, base 00001860, size 4, enabled map[24]: type 1, range 32, base 00000000, size 10, memory disabled found-> vendor=0x8086, dev=0x248a, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 00001880, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 11 found-> vendor=0x8086, dev=0x2483, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[10]: type 4, range 32, base 00001c00, size 8, enabled map[14]: type 4, range 32, base 000018c0, size 6, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 11 found-> vendor=0x8086, dev=0x2485, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[10]: type 4, range 32, base 00002400, size 8, enabled map[14]: type 4, range 32, base 00002000, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB) pcib0: slot 31 INTB is routed to irq 11 found-> vendor=0x8086, dev=0x2486, revid=0x02 bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 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 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xd0100000-0xd01fffff pcib1: prefetched decode 0xe8000000-0xefffffff ACPI PCI link initial configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 ACPI PCI link before setting link priority: ACPI PCI link before fixup for boot-disabled links: ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe8000000-0xefffffff map[14]: type 4, range 32, base 00003000, size 8, enabled pcib1: device (null) requested decoded I/O range 0x3000-0x30ff map[18]: type 1, range 32, base d0100000, size 16, enabled pcib1: device (null) requested decoded memory range 0xd0100000-0xd010ffff pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA) pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x1002, dev=0x4c57, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0387, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 8 pcib2: I/O decode 0x4000-0x8fff pcib2: memory decode 0xd0200000-0xdfffffff pcib2: prefetched decode 0xf0000000-0xf80fffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.2 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.1.0 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.1 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.2 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.1 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.2 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.3 \\_SB_.LNKE irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.8.0 ACPI PCI link before setting link priority: ACPI PCI link before fixup for boot-disabled links: ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.0.2 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.1.0 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.1 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.2 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.2.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.1 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.2 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.4.3 \\_SB_.LNKE irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 2.8.0 pci2: on pcib2 pci2: physical bus=2 map[10]: type 1, range 32, base 50000000, size 12, enabled pcib2: device (null) requested decoded memory range 0x50000000-0x50000fff pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKA) pcib2: slot 0 INTA is routed to irq 11 found-> vendor=0x104c, dev=0xac55, revid=0x01 bus=2, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 51000000, size 12, enabled pcib2: device (null) requested decoded memory range 0x51000000-0x51000fff pcib2: matched entry for 2.0.INTB (src \\_SB_.LNKB) pcib2: slot 0 INTB is routed to irq 11 found-> vendor=0x104c, dev=0xac55, revid=0x01 bus=2, slot=0, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0107, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base f8000000, size 12, enabled pcib2: device (null) requested decoded memory range 0xf8000000-0xf8000fff pcib2: matched entry for 2.2.INTA (src \\_SB_.LNKC) pcib2: slot 2 INTA is routed to irq 11 found-> vendor=0x1260, dev=0x3873, revid=0x01 bus=2, slot=2, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base d0200000, size 12, enabled pcib2: device (null) requested decoded memory range 0xd0200000-0xd0200fff map[14]: type 4, range 32, base 00008000, size 6, enabled pcib2: device (null) requested decoded I/O range 0x8000-0x803f pcib2: matched entry for 2.8.INTA (src \\_SB_.LNKE) pcib2: slot 8 INTA is routed to irq 11 found-> vendor=0x8086, dev=0x1031, revid=0x42 bus=2, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 cbb0: mem 0x50000000-0x50000fff irq 11 at device 0.0 on pci2 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac55104c 0x02100107 0x06070001 0x00824008 0x10: 0x50000000 0x020000a0 0xb0050302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x05121014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d071 0x00000000 0x00000000 0x01d21022 0x90: 0x406402c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x0000000b 0x0000000f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0x51000000-0x51000fff irq 11 at device 0.1 on pci2 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x51000000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac55104c 0x02100107 0x06070001 0x00824008 0x10: 0x51000000 0x020000a0 0xb0080602 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740020b 0x40: 0x05121014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d071 0x00000000 0x00000000 0x01d21022 0x90: 0x406402c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x0000000b 0x0000000f 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 wi0: mem 0xf8000000-0xf8000fff irq 11 at device 2.0 on pci2 wi0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf8000000 wi0: [GIANT-LOCKED] wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi0: bpf attached wi0: Ethernet address: 00:05:3c:03:86:b9 wi0: bpf attached wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: bpf attached fxp0: port 0x8000-0x803f mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd0200000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1031 1014 0209 0042 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:09:6b:c2:86:92 fxp0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x3f4 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 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x374 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 mask=03 stat0=00 stat1=00 devices=0x4 ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ichsmb0: port 0x1880-0x189f irq 11 at device 31.3 on pci0 ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.5 (no driver attached) pci0: at device 31.6 (no driver attached) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0047 psm0: flags 0x2000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00002000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0: cannot reserve I/O port range (1 ports) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A unknown: not probed (disabled) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 acpi_ec0: Changing GLK from 1 to 0 unknown: not probed (disabled) acpi_cmbat0: on acpi0 unknown: not probed (disabled) acpi_acad0: on acpi0 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) fdc0: cannot reserve I/O port range (1 ports) unknown: not probed (disabled) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 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 sio: sio0 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 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: