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