From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 29 12:21:50 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 1458116A4CE for ; Thu, 29 Apr 2004 12:21:50 -0700 (PDT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0079043D48 for ; Thu, 29 Apr 2004 12:21:50 -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; Thu, 29 Apr 2004 12:21:49 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4B3F75D0B; Thu, 29 Apr 2004 12:21:49 -0700 (PDT) To: Lukas Ertl In-reply-to: Your message of "Thu, 29 Apr 2004 20:16:18 +0200." <20040429201041.W751@leelou.in.tern> Date: Thu, 29 Apr 2004 12:21:49 -0700 From: "Kevin Oberman" Message-Id: <20040429192149.4B3F75D0B@ptavv.es.net> cc: acpi@freebsd.org Subject: Re: Suspend/resume regression with latest ACPI 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, 29 Apr 2004 19:21:50 -0000 > Date: Thu, 29 Apr 2004 20:16:18 +0200 (CEST) > From: Lukas Ertl > Sender: owner-freebsd-acpi@freebsd.org > > Hi, > > I'm seeing a suspend/resume regression with the latest ACPI code. Last > known good kernel was from April 12th, so that was before the import of > ACPI CA 20040402. > > The box in question is a ThinkPad T40, and with the old kernel, I could > perfectly suspend/resume my laptop. Now, only the first suspend/resume > cycle works; if I try afterwards, it immediately wakes up again after > suspending. No errors or otherwise suspiscous output. > > I'm not sure if this could be related to the PCI changes from Warner. This is a me-too (tm-AOL). In my case it's an IBM T30. Looks like the problem may be common to multiple IBM systems. I've seen some other reports of this on IBMs, but I'm not sure if I've seen reports on other platforms. I'm seriously suspicious that this is really a PCI issue in the power stuff. I suspect that something is not being properly reset on resume and that the next attempt to suspend fails because something is not in the right state. It gets all the way to the end of the suspend, though, before it decides that it really can't. I have a couple of other problems that I think are really PCI issues (sound and the loss of IRQ11 after a while) and I think that this should also go on the list. -- 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